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ABSTRACT OF THE DISCLOSURE 
A system for monitoring and configuring gaming devices 
interconnected over a high-speed network is disclosed. The system can 
support a file server, one or more floor controllers, one or more p.t 
terminals,andotherterminalsaUinterconnectedoverthenetv,ork.Each 

gaming device includes an electronic module which allows the gammg 
device tocommunicatewithafloorcontrolleroveracurrentloopnetwork. 

The electronic module includes a player tracking module and a data 
communication node. The player tracking module includes a card reader 
for detecting a player tracking card inserted therein which identifies the 
player The data communication node communicates with both the fioor 
controller and the gaming device. The data communication node 
communicates with the gaming device over a serial interface through 
which the data communication node transmits reconfiguraUon 
commands. The gaming device reconfigures its payout schedule 
responsive to the reconfiguration commands to provide a varxety of 
promotional bonuses such as multiple jackpot bonuses, mystery jackpot 
bonuses, progressive jackpot bonuses, or player specific bonuses. 
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BACKGROUND OF THE IISVENTION 
This invention relates generally to gaming devices, and more 
particularly to a method and apparatus for controlling gaming devices 
interconnected by a computer network. 

Networked gaming devices are know in the art. Interconnecting a 
plurahty of gaming devices such as slot machines via a computer network 
to a central computer provides many advantages. The primary advantage 
of networked gaming devices is the ability to extract accounting data from 
the individual gaming devices as well as providing player tracking. An 
example of a data collection system is described in U.S. Patent No. 
4,283,709 issued to Lucero et al. Network systems such as described in 
Lucero et al. allow the central host computer to monitor the usage and 
payout, collectively known as audit data, of the individual gaming 
devices. This audit data includes data related to the number of coins or 
tokens inserted into the device, the number of times the device has been 
played, the amount paid in raises, the number and the type of jackpots 
paid by the machine, the number of door openings, etc. The host 
computer can then compile an accounting report based on the audit data 
from each of the individual gaming devices. This report can then be used 
by management, for example, to assess the profitability of the individual 
gaming devices. 

Player tracking, as the name indicates, involves tracking individual 
player usage of gaming devices. In prior art player tracking systems, the 
player is issued a player identification card which has encoded thereon a 
player identification number that uniquely identifies the player. The 
individual gaming devices are fitted with a card reader, into which the 
player inserts a player tracking card prior to playing the associated 
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gaming device. The card reader reads the player identification number off the 
card and informs a central computer connected thereto of the player's 
subsequent gaming activity. By tracking the individual players, individual player 
usage can be monitored by associating certain of the audit data with the player 
5 identification numbers. This allows gaming establishments to target individual 
players with direct marketing techniques according to the individual's usage. 

One problem that can occur with prior art player tracking systems is that the 
player can insert a player identification card incorrectly unbeknownst to the 
player. In such prior art player tracking systems, if a player inserts a player 
10 identification card improperly into the card reader, a message appears on a 
display located away from the card reader. Unfortunately, the player may not be 
looking at the display while inserting the card. As a result, the player may not 
see the message on the display. Another prior art approach has been to provide 
a light emitting diode on the gaming device to indicate to the player the status of 
15 the card insertion. This too has been ineffective because the player may not 
know the purpose of the LED or the LED may be drowned out by all the other 
lights of the casino. The player may therefore commence playing with the card 
improperly inserted. In this case, both the player and the casino lose valuable 
player tracking information. This is frustrating for the player because his activity 
20 will not be credited to his account and frustrating for the casino because the 
casino's records will be incomplete. Accordingly, a need remains for an 
improved method and apparatus for informing the player when a player tracking 
card has been improperly inserted. 

The full power of networked gaming devices has not been completely realised. 

25 Although the audit data indicates which devices are being under utilised and 
when, the prior art provides no automated method for altering under utilised 
gaming devices' configurations to make them more attractive to play. For 
example, during certain hours of the day, e.g. four to six a.m., the audit data may 
indicate that the machines are being under utilised. Thus, it would be desirable 

30 to reconfigure the under utilised gaming devices to provide an additional 
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incentive to players to use these devices. In the past casinos have run 
"bonuses" during these times. An example of such bonuses include a "double 
jackpot" wherein a player hitting a jackpot is paid double the jackpot amount. 
Currently this is implemented by having an attendant manually payout the 
5 additional payout amount. This manual technique, however, is cumbersome and 
inefficient to administer because an attendant must be constantly supervising the 
bonusing gaming devices. Accordingly, a need remains for an automated 
method and apparatus to provide bonusing for gaming devices. 

Another limitation of prior art bonusing systems is that only predetermined 
10 machines are eligible for the bonusing. For example, in a progressive bonusing 
machine a plurality of machines are connected together to form a bank. Only 
the machines in the bank are then eligible to win the progressive jackpot. Thus, 
a casino must dedicate a certain number of its machines to these banks. This 
limits the casino's flexibility in tailoring its bonusing to the number and make-up 
15 of its customers. Accordingly, a need remains for a more flexible bonusing 
system whereby any of the casino's machines can participate in the bonusing. 

In accordance with a first aspect of the present invention there is provided a 
method of operating gaming devices interconnected by a computer network to a 
host computer having a user-operated input device comprising: 

20 associating each gaming device with a unique address code; 

preselecting less than all of the gaming devices interconnected by the 
computer network responsive to a user-effected action at the input device 
that identifies the preselected gaming devices with the respective 
associated address codes; 

25 using the network to track the amount of money played on the 

preselected gaming devices; 
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allocating a predetermined percentage of the money played to a bonus 
pool; and 

issuing a command over the network to cause a bonus to be paid from 
5 the bonus pool by one of said preselected gaming devices upon the 

occurrence of a predetermined event. 

Preferably, the preselected gaming devices comprise a first group of gaming 
devices made up of less than all the gaming devices interconnected by the 
computer network and wherein said method further comprises: 

10 preselecting a second group of gaming devices responsive to a user- 

effected action at the input device; 

using the network to track the amount of money played on the second 
group of gaming devices; 

allocating a predetermined percentage of the money played on the 
15 second group of gaming devices to a second bonus pool; and 

issuing a command over the network to cause a second bonus to be paid 
from the second bonus pool via one of said gaming devices in the second 
group upon the occurrence of a second predetermined event. 

Preferably, the predetermined event comprises a transaction at the gaming 
20 device to which the bonus is paid. 





The description of the invention with reference to the accompanying drawings 
herein describes a system for operating networked gaming devices. The system 
allows a casino in which the system is installed to run promotions or bonuses on 
5 any properly equipped gaming machines while simultaneously gathering player 
tracking and accounting data from all machines. The system provides the 
capability for the casino to select which of the plurality of machines are used In 
any given promotion. The system further allows any number of different 
promotions to operate simultaneously. 

10 The system includes a plurality of gaming devices or machines connected to an 
associated floor controller over a network. The system includes one or more of 
said floor controllers. The floor controllers are interconnected by a high-speed 
network, such as an Ethernet network, to a database where accounting and 
player tracking data is stored. The system can also include pit terminals and/or 

15 fill and jackpot processing terminals. Each promotion involves sending a 
reconfiguration command from the floor controller to a gaming device that has 
been selected to be part of a given promotion over the associated network. 
Upon receipt of the reconfiguration command, the gaming device reconfigures its 
payout schedule in accordance with the received reconfiguration command. In 

20 the preferred embodiment, this reconfiguration includes activating a bonus 
payout schedule. A partial list of the promotions available include, but are not 
limited to: a multiple jackpot wherein the gaming device reconfigures its payout 
to be a multiple of its default payout schedule; a bonus jackpot wherein the 
gaming device reconfigures its payout schedule to payout an additional bonus 

25 amount when certain conditions are met; and a progressive jackpot wherein two 
or more gaming devices are combined in a progressive jackpot having a 
progressive jackpot payout schedule. In addition to these, many other 
promotions are possible by the above-described system for controlling and 
monitoring a plurality of gaming devices. 
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The system also allows for improved player tracking by recording each and 
every machine transaction including time of play, machine number, duration of 
piay, coins in, coins out, hand paid jackpots and games played. The player 
tracking is conducted over the same network as the accounting data is 

5 extracted. This allows the invention to provide bonusing to certain individual 
players as well as during certain times. As with standard player tracking, the 
above-described system monitors and reports how many coins are played by 
each player. The system according to the invention, however, also includes the 
ability to record how long each player spends at each machine and the number 

10 of coins won, games played, and hand jackpots won by each player. All this 
information is able to be recorded because the system operates on a transaction 
by transaction basis. Each transaction, whether it be a coin in, a handle pull, 
etc., is recorded by the system. Other systems simply compile the player 
tracking information at the completion of play. All this information is stored on 

15 the database, which can be later analysed for future targeted direct mailing 
campaigns. The player tracking also allows the casino to schedule buses and 
other groups and measure their profitability. The system also allows for cashless 
play as well as advanced accounting and security features. 

BRIEF DESCRIPTION OF THE DRAWINGS 



20 The present invention will now be described, by way of example, with reference 
to the accompanying drawings, in which: 

Figure 1 is an illustration of an embodiment of a system for monitoring 
and configuring gaming devices according to the invention. 

Figure 2 is a block diagram of an embodiment of an electronic module 
25 associated with each gaming device to permit monitoring and configuring 

thereof. 
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Figure 3 is a schematic diagram of a data communication node of the 
electronic module of Figure 2. 

Figure 4 is a schematic diagram of a discrete machine interface circuit of 
the electronic module of Figure 2. 

Figure 5 is a schematic diagram of a player tracking module of the 
electronic module of Figure 2. 



Figure 6 is a schematic diagram of a card reader circuit of the electronic 
module of Figure 2. 



FIG. 7A is an exploded view of a card reader according to the 

invention. rxi^T/-' n\ 

FIG 7B is a rear perspective view of the card reader of FIG. 7A. 
FIG 7C is a front perspective view of the card reader of FIG. 7A. 
FIG. 8 is a schematic diagram of a display circuit of the player 

tracking module of FIG. 2. ^ r- ^i, 

FIG. 9 is a schematic diagram of a personality board of the 

electronic module of FIG. 2. . r 

FIG. 10 is a schematic diagram of a triac driver circmt of the 

electronic module of FIG. 2. . r 

FIG. 11 is a schematic diagram of a relay driver circmt of the 

electronic module of FIG. 2. , 4 ■ 

FIG. 12 is a block diagram of a communication board included in 

each floor controller of FIG. 1. 

FIG 13 is a flow chart for the power-on procedure for the data 
communication node (DCN) of FIG. 2, which is implemented in firmware 
executed by the DCN controller. 

FIG. 14 is a flow chart for processing of the discrete gammg device 

inputs, of FIG. 13. 

FIG 15 is a flow chart for the step of incrementing meter counts 
associated with each gaming device of FIG. 14. which is implemented m 
firmware executed by the DCN controller. 

FIG 16 is a flow chart for the step of processing the serial mterface 
between the gaming device and the data communication node of FIG. 13, 
. which is implemented in firmware executed by the DCN controller. 

FIG 17 is a flow chart for the step of processing the network 
mterface between the floor controller and the data communication node 
of FIG. 13, which is implemented in firmware executed by the DCN 
controller. 



FIG 18 is a flow chart for the step of processing the network 
„>essage of FIG. 17, which is in,pie„ented in f.rnoware executed by the 

DON controller. processing the data 

FIG 19 is a flow chart for the step i 

I „f TfTfi 18 which is implemented in 
communication node request of HG. IB, w 

firmware executed by the DON controller. 

player tracking interface, which is implemented in firmware executed by 

the DON controller^ ^ ^^^.^ .^^^^^^ 

FIG. 21 is a flow chart for the step oi p 

card of FIG. 20, which is implemented in firmware executed by the DON 

FIG 22 is a flow chart for the step of processing player tracking 
information of FIG. 21, which is implemented in firmware executed by the 

a flow chart for the power-on procedure for the player 
tracking (FT, node of FIG. 2, which is implemented in firmware executed 

by the PT controller. nrw interface 

FIG. 24 is a flow chart for the step of processmg the DON mt rface 
, „t FIG. 23, which is implemented in firmware executed by the PT 

25 is a flow chart for the step of processing the DCN message 
of FIG. 24, which is implemented in firmware executed by the PI 

"""'to. 26 is a flow Chart for the step of processing the card reader 
hezel update of FIG. 23, which is implemented in firmware executed by 

flow Chart for the step of processing the card reader of 
FIG. 23, which is implemented in firmware executed by the PT controller. 
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FIG 28 is a flow chart for the power-on floor controller process, 
which is in.p.en>ented in software executed h, the floor controller. 

FIG 29 is a flow chart for the message processing step of FIG. 28, 
which is implemented in software executed by the floor controller^ 

FIG 30 is a flow chart for the message handhng step of FIG. 29, 
wWch is implemented in software executed by the floor controller. 

FIG 31 is a flow chart for the step of assigning un.que mach ne 
addresses of FIG. 30. which is implemented in software executed by the 

floor controller. ^rx?in or 

FIG 32 is a flow chart for the system monitonng step of FIG. 28, 

.hich is implemented in software executed hy the floor ^^^^^^^^^^ 

FIG 33 is a flow chart for the event handling step of FIG. 32. whxch 
is implemented in software executed by the floor controller. 

FIG. 34 is a flow chart for bonus control, which is implemented m 
, software executed by the floor controller. 

DETAILED DESCRIPTION 
Table-fili^iiiil^ni^ 
I. SYSTEM ORGANIZATION 
^ SYSTEM OVERVIEW 
g DATA COMMUNICATION NODE 

1. Overview 

2. CONTROLLER AND MEMORY 

3. NETWORK INTERFACE 

A SERIAL MACHINE INTERFACE 

25 

5. SERIAL DISPLAY INTERFACE 

6. DISCRETE MACHINE INTERFACE 

7. MACHINE CONFIGURATION 
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3. PLAYER TRACKING MODULE 
1. OVERVIEW 

2 SERIAL DISPLAY CIRCUIT 

3 SERIAL EXPANSION PORTS 

4. Card reader 

5. Display 

6. DISCRETE INPUT SECTION 

D. PERSONALITY BOARD 

E. BONUS DISPLAY DRIVERS 

F. FLOOR CONTROLLER 
OPERATION 

A. DATA COMMUNICATION NODE 

1 POWER UP PROCEDURE 

2 READING UNIQUE IDENTIFICATION NUMBER 

3 MONITORING GAMING DEVICE DISCRETE INPUT 
4. PROCESSING GAMING DEVICE SERIAL INTERFACE 
5 PROCESSING NETWORK INTERFACE 

6. PROCESSING PLAYER TRACKING INTERFACE 

7. PROCESSING CARD INSERTION 
B. PLAYER TRACKING MODULE 

1. POWER UP PROCEDURE 

2. PROCESSING DON INTERFACE 

3. PROCESSING DISPLAY UPDATE 

4. PROCESSING BEZEL UPDATE 

5. PROCESSING CARD READER 
C. FLOOR CONTROLLER 

1. POWER UP PROCEDURE 

2. MESSAGE PROCESSING 

3. ASSIGNING GAMING DEVICE ADDRESSES 
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4. SYSTEM MONITORING 

5. BONUS CONTROL 

I. SYSTEM ORGANISATION 
A. SYSTEM OVERVIEW 

5 A system for operating a plurality of gaming devices is shown generally at 10 in 
Figure 1. The system, hereinafter described, monitors and reconfigures a 
plurality of gaming devices or machines 12-16 and 22-26. The system Includes 
the following capabilities: remote reconfiguration, accounting data extraction, 
integrated player tracking, and cashless play. Remote configuration includes 

10 sending a reconfiguration command from a host computer to one or more of the 
gaming devices. The gaming devices, on receiving a reconfiguration command, 
will reconfigure its jackpot payout schedule in accordance with the 
reconfiguration command. 

This reconfiguration, in the preferred embodiment, comprises activating a bonus 
15 payout schedule. This bonus payout schedule is in addition to the normal pay 
table of the gaming device. This bonus payout schedule provides for additional 
bonus payouts in addition to the payouts specified by the device's normal pay 
table. The difference between the two may be important for regulatory reasons. 
For example, in the United States of America, the composition of the pay table is 
20 subject to regulation by the various state gaming commissions while the bonus 
payout schedule is not. The preferred embodiment currently activates only the 
bonus payout schedule responsive to the reconfiguration command, while not 
altering the payout table. The invention, however, is not limited to activating only 
the bonus payout schedule. Other embodiments, which would be subject to 
25 regulatory approval, could modify the device's payout table. The preferred 
embodiment, however, does not. 



The Byslem. according to the invention, implements a variety of 
bonusing events through this reconfiguration process. These bonusmg 
::sinc,uae:amu.tip,ejacKpotwhereinthe.amingaevicereco„f.gures 

US payout to be a multiple otits default payout schedule; a bonus.acUpot 
lir rein the gating device reconfigures its payout schedule to payout a 
additional bonus amount when certain conditrons are -t and a 
progressiveiackpot wherein two or more gaming devices are corr*med 
a progressive jackpot having a progressive iackpot payout schedule. 

The system, according to the invention, also provides for mtegrated 
player tracking and accounting data extraction. Unlike prior art systen^s 
Ihat use disparate systems for player tracking and accountmg da a 
extraction, the system 10 provides for player tracking and accoun Ung 
data extraction over the same network. The player trackmg, accordrng 
to theinvention,allowsthe casino to run certain promot,ona events. Ihe 

Tntegrated player trackingandaccountingdataextractionalsoallows the 
ryrrltosLortcashlessplaywhereinacreditisgiventoaplayerover 

tystem .0 incudes one or more fioor controllers « and .8. 
Each floor controller supports up to a predetermined maximum nunoher 
!f gaming devices. In the preferred embodiment, each floor controller can 
upport up to 1024 gaming devices. The preferred embodiment also 
supports up to eight floor controllers. Thus, the system 10 can support up 
to 8192 separate gaming devices. , • „ it,„ 

The system supports a multiplicity of various gammg devces. The 
. gaming devices 12-16 and 22-26 shown in FIG. 1 are the type havmg a 
pun h ndle for initiating a game. e.g.. slot machines. However, the 
nvention is not limited to such gaming devices. The gammg de.ce 
.hown in KIG. 1 can also be gaming tables or P"* — 
machines as well. e.g. video poker. As will be ^^-"^^'^^^^'^^^ 
system supports any gaming device providmg trad.Uona, drscrete 
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connections, e.g.. coins-in, coins-out. etc.. as well as t.ose havin. se.ial 

interfaces, as described below. embodiment. 
The floor controllers 18 and 28 are, m tne p 

fov« Fich floor controller is responsible 
IBM-compatible personal computers. Each floor 

. . nativity level of the correspondmg gammg devices 

:::Uu.e ... ..o.. s......s ..... e... ; 

The floor controller, issue status requests to each of ^"-"'^-'^"^ 
devices to determine the activity leve, oteach. In the even the 
Z cltroller detects any activity, the floor controller con>mun,cates 
:::::::tytoa«eserver3.,wMchisconnectedtothefloorcontro,.ers 

vlaal,!.!. speed „etwor.38 connected— ^ ^^^^ 

In the preferred embodiment, the file server 
perrorn>anceper.ona,con>puteror»or.statlonhav™.alar.e^^^^^^^^^ 

Lacity in order to store the gaming device act,v.ty there.n. In the 
e d e^bodmrent, the high speed network 38 is a ten .egaby^^e 
e Let network. The system 10 also includes con,™erc,a.,y available 
Ilrksoltwaretosupporttheindustry-standardethernetnetworUaS^ 
, <■ .h network software is Novell network software sold by 
An example of such network soltw i„dudes a database 

TT4- V. TVx*^ flip server 32 also inciuaeh> vacx 

me Lver Such reports include, e.g. area, model, denonnnat.on and 
, The database software also allows a user to generate 
summary reports. The database soi industrv- 
custom reports. The database software is based on the mdustry 
cjtnndard Paradox database language. 

The system 10 also includes a pit terminal 34 which ,s also 
eonneld L the ethemet network 3B. The pit terminal 3 -s a so 
standard personal compu,.r, in the preferred ^^^^^^ 
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'i^^'.r^cr rlf^vice to detect any 
ric, n security monitoring device 
can also be used as a secuiij 

ftom which security can then be alerted. 

A fill and jackpot processing terminal 36 prmts a 1 

. I f the calculated hopper balance was nearly zero, the terminal 

;irr:::r::Ji.*.— ^^^^ 

Th*> <^vstem follows a similar proceaure lui f 
fill transaction, ine system lui 

security events and direct ouic rr.u«^and 
• t.lv For example, during hopper empties (fills) and 
situations appropriately, borexamp , j:«nntrher 
\ indicated by the dispatcher station, the dispatcher 
jackpot events, as indicated oy 

. ^ fi.^ flnnr to have someone verify the event, 
could radio down to the floor to na 
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.ispatche. station can also indicate when a n.ach.ne door . opened 
without a technician card inserted, for example, -n wh,ch case the 
dispatcher could take the appropriate course of acUon. 

Theabove-describedsystemlOishutoneembodin.entofthesysten, 

according to the invention. The eysten. tasUs can be allocated in a .ar.ety 
of«aysan,on.stthesyste™con.putersinc,udingfloorcontrol.ers sand 

28 me server 32, pit terminal 34 and fiU and jaclcpottermmals 36. In 
some cases, the pit tem^inal 34 and mi and jacUpot terminals 36 can ev^n 
be eliminated and their tasks allocated to the floor control er or fi e 
s rver In fact, because the me server 32 is essentially a v.rtual hard drsk 
L the floor controllers 18 and 32. the floor controllers and the file server 
can be considered a single host computer for the system 10. 
B. DATA COMMUNICATION NODE 
1 OVERVIEW 
order to communicate with the floor controller, each gaming 
device includes therein an electronic module 40, as shown m FIG. 2. 
module 40 can be inserted into a variety of pre-existing gammg dev.ces^ 
Z module allows the host computer to unicuely identify the gamm. 
iceonthenetwork.includingthedevicotype.Themodule40mcludes 

two main subcomponents: a data communication node 42 and a playe 
tracking module 44. The data communication node 42 keeps track of th 
eoins-in, coins-out, coins to drop, games played, jackpot oc— 
other related functions of the associated gammg dev.ce. The player 
.racking module 44 keeps track of the player that is playmg h 
, associatedgamingdevice.Together,thedatacommumcatmnnde^^^^^^^^^^^ 

the player tracking module 44 allow the floor controller connected to he 
Iciated gaming device W monitor and control the -tiv. y of - 
gaming device. The system hereinafter described in deta.l mcludes the 
following capabilities: slot accounting, player tracking, bonus .ackpots 
30 and cashless play. 



2 CONTROLLER AND MEMORY 

The data communication node (DON) 42 includes a data 
communication node controller 46. which in the preferred embodiment ,s 
In HD64T3258P10 controller manufactured by Hitachi otToUyo, Japan. 
The DCN 42 is coupled to the player tracking controller 44 through bus 
interface logic 45. The bus interface logic 45 is conventional interface 
logic including, for example, transceivers, as is k„o«n in the art of d.grtal 

'"'""a memory 48 is connected the DON controller 46. The memory 
includes program memory for storing program instructions for the DON 
controller 46. In the preferred embodiment, this program memory 
includes a nonvolatile read-only memory (ROM). However. th,s program 
memory could also be flash or "battery- backed HAM in order for the 
progral memory to be updated by the floor controller. In the even fla* 
or -battery" back RAM is used the floor controller would download the 
updated program to the DCN controller and the DCN controller would 
overwrite the program memory with the downloaded program. 

The memory 48 also includes system memory, e.g., statrc random- 
access memory <SRAM) for storing the gaming device '"^0™^"™- J^^-J 
gaming device information includes at least the followmg meters, coms^ 
n. coins-out, coins to drop, games played. Jackpot occurrences^ A 

increase reliability of the data, in the preferred embodiment, a redundant 
set of these counters is kept in a physically separate memory devrce 
, within memory 4B. Moreover, the memory devices storing these coun^rs 

3re nonvolatile so that in the event of a power failure the -nts^^ 
retained. Thenonvolatilememoriescaneitherbebattery-backedS^ 

or electrically erasable programmable read-only memory (™MX 
Although memory 48 is shown external to DCN controller 46. much ,f not 
30 all of the memory 48 can be included in the DCN controller 46. 



3 NETWORK INTERFACE 

• „^Hp 42 also includes a network interface 

The data communication node 4^ also m . , . n . 

controller. The network interface .s coupled to 
through a personality board 202, described below. 

A»ore detailed drawing of network interface 49 rs shown ,n F a 
3lnFIG.3.theBCNco„troner4ereceivesdatafro™thefloorco„tro,. 

ductor 52 which is optically isolated from a connector 61 by 
over conductor 52 w ^^^^ ^ 

optical isolator orcu,t 54^ The DC ^^^^^^^^ ^^^^ 

floor controller over conductor ^6, -h;* P „pto-isolator 
connector 51 by optical isolator crrcurt 58. Each P 
arcuits54and5Bincludeanopto-eouplerasarekno— 

222 (FIG. 2) is connected between the network interface 

personality board 202. 

4 SERIAI, MACHINE INTEEFACE 

Referring to FIG. 2, the data comn-unication node includes a ser.al 
H e interface 60 The serial machine interface 60 allows the data 
machine interface 6 ^^.^^^ ^j^vi the associated gaming 

communication nod^ 42^ - ^^^^ 
device advance serial interface a ^^^^^^^^ 
to be described further heremafter. A bus 224 ( ^^^^^ 
serial machine interface 60 to the associated gammg device 
62 The serial interface, in the pi^ferred embodiment, is a standard RS- 
232 three wire interface^ ^^^^^^^ ^^^^^^^^ ^^^^ 

Referrmg to FIG. 3, D ^^^^^^^ 
>5 gaming device over conductor 64 wh.cn IS n-he DON 

ontroller 46 and a differential to ^'-'--^^''/""^-"j/l^l^reS 
controller 46 transmits data to the gaming device over 
connected between the DCN controller 46 and the converter 66. The 
connecteo differential inputs of the serial interface 62 to 

converter 66 converts the dillerentia. mp fiii„tlieDCN 
, 3i„gle-e„ded output which is transmitted over conductor 64 to 
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eontroUe. 46. The converter 66 also converts the sing.e-ended .nput 
received fron> the DCN controller 46 to a differential output srgnal and 
transmits that to the serial interface 62. The serial nrach.ne interface s 
the means by which the DCN controller con^mun.cateB cert >n 
reconn^ration data, referred to as reconnguration commands, to the 
machine. These reconfiguration commands cause the mach.nes t. 
activate a bonus payout table to allow the machine to append bonus 
payments to their standard Jackpot payouts, as specified by the.r payout 

table, during certain bonus activities. 

5. SERIAL DISPLAY INTERFACE 

• 1- A9 further includes a serial display 

The data communication node 42 turtner mciu 

interface 70 illustrated in more detail in FIG. 3. The serial display 
interface 70 includes logic coupled between the DCN controller 46 and an 
expansion connector 71. The expansion connector 71 allows he DCN 
controller 46 tocommunicate with an expansiondeviceconnected thereto. 

6. DISCRETE MACHINE INTEREACE 

• 4.- ^ r.r.A^ 49 nlqo includes a discrete machine 
The data communication node 42 also mom 

interface 72, which is shown in detail in FIG. 4. The discrete machme 
interface 72 includes a plurality of opto-couplers 78 coupled between tt,e 
discrete outputs from the gaming device or machine and the DCN 
controller 46. The discrete outputs of the machine are rece.ved at 
tirminals 74A.74J of a connector 74 via a cable (not shown) connected 
between the machine and the connector 74. The discrete outputs are 
coupled to corresponding inputs 76A-76J via opto-couplers 78 Jhe 
- discrete outputs from the machine include: an EXTRA s.gnaM POWER 
' al a COIN IN signal, a COIN OUT signal, a COIN DROP s.gnal, a 

jIcKPOT signal, a HANDLE signal, a TILT s.gnal, a SLOT DOOR 
signal and a DROP DOOR signal. Each of these signals correspond to a 
.now: event in the machine. For example, when a coin '=_^-P>-^- 
machine a COIN IN signal appears on terminal 74C. Th.s COIN IN 
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signal is then transmitted to the DCN controller 46 on line 76C via the 
associated opto-coupler. 

All of the signal lines 76A-76J include a puUup res.stor and a 
pulldown capacitor, which co,nbined form an RC network on the 
ociated line. The resistors are. in the preferred embodiment ,n the 
form of a resistor pa* 80 and the capacitors are indiv.dua. discrete 
capacitors 82, Alternatively, the capacitors can be removed for h.gh- 

speed signals. 

7 MACHINE CONFIGURATION CIRCUIT 

• r.A^ 49 shown in FIGS. 2 and 3, 

The data commumcation node 42, as snown 

further includes a machine conBguration circuit 84. In the preferred 
embodiment, as shown in FIG. 3, the machine configuration c>rcu>t 84 
includes a parallel to serial converter 86, which includes paraUe. 
inputs m, a serial input SIN, a clock input CLK, a strobe mput STB, and 
a serial output SOUT. The parallel inputs IN are connected to 
personality board, as described hereinaaer, to receive a 
Infiguration number therefrom, which uniquely identifies the type of 
machine that the data communication node is connected to. In the 
preferred embodiment, the machine identification number is comprrsed 
of six bits. Therefore, the two remaining parallel inputs can be used U. 
provide additional inputs, such as additional discrete machine inputs, to 

the DCN controller 46. 

Themachineconfigurationnumberpresentedontheparallelmputs 

of the parallel to serial converter 86 is latched therein responsive to a 
, strobe signal received at the strobe STB input. A strobe mput ,s 
generated by the DCN controller 46 on conductor 90 wh>ch .s coup ed o 
he strobe STB input. The parallel data is clocked out of the converter 86 
:! the DCN controller 46 on conductor 88 and connecte between 
serial output SOUT of the converter 86 and an input "J ^he BCN 
controller 46 responsive to a clock si^a, received on the clock mput CLK 
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of the converter 86. The clock signal is generated by the DCN controller 
46 and is transmitted to the converter 86 via conductor 92 which is 
coupled between an output of the DCN controller 46 and the clock xnput 

CLK of the converter 86. 

The converter 86 also includes a serial input SIN for receiving serial 
input data. The serial input SIN is coupled to an expansion terminal 94C 
of expansion connector 94. Conductors 90 and 92 are also coupled to the 
expansion terminal 94 to provide the clock and strobe signals thereto. 
The expansion terminal 94 therefore provides the means for the DCN 
controller 46 to access additional serial information through the parallel 
to serial converter 86. In the preferred embodiment, the parallel to serial 
converter 86 is part number 4021 manufactured by Toshiba Corporation 

of Tokyo, Japan. 

C. PLAYER TRACKING MODULE 
1 Overview 

Referring again to FIG. 2, the module 40 coupled to each of the 
gaming devices includes a player tracking module 44. The player 
tracking (PT) module 44 includes a player tracking controller 98, a card 
reader 100, a serial display driver 101, a display 102, and expansion 
interfaces 104 and 106. The player tracking controller 98 communicates 
with the data communication node controller 46 through bus interface 
logic 110 The DCN controller 46 and PT controller 98 maintam a 
nvaster-slave relationship, respectively. Therefore, all communication is 
initiated by the DCN controller 46. The bus interface logic is 
conventional logic and its design is well-known in the art of digital 

electronics. . 

In the preferred embodiment, the player tracking module 44, with 
the exception of the card reader 100 and the display 102, resides on a 
single printed circuit board, while the data communication node 42 
30 resides on a separate printed circuit board. The player tracking module 
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. „^rlo 49 are then connected by a cable 111 

44 and the data communication node 42 aie then 

such as a ribbon cable. 

2 SERIAL DISPLAY CIRCUIT 

Amore detailed drawing of the player tracking module 44 is shown 
i„ FTO. 5. In FIG. 5. the serial display circuit 101 includes a transistor 
Ql and a resistor Rl connected to the base thereof. A conductor 112 .s 
connected between the PT controller 98 and the resistor Rl to prov.de^ 
drive signal to transistor Ql. The drive .ignal causes tran.stor Ql to 
Induct a current and thereby drive a display connected to the col^^or 
of qi at atern>inal 114 of aconnector U5. In the preferred , 
th!tem.inal 114 is connectahle a sn>all vacuunr florescent display to 
provide serial display data thereto. 

3 SERIAL EXPANSION PORTS 
The player tracking n>odule 44 also includes two serial expansion 
,orts 104 and lOe. .ach of the expansion ^^^^^Z 
differential to single-ended converter 116 and 118. respectively 
p^eferred en.hodin.ent, these converters 116 and 118 are part nu^^ er 
ItC490 „>anufactured by Linear Technology Corporation of Mr P-tas 
Cahfornia. The PT controller 98 coinmunicates with each converter via 
two single-ended, serial signal lines: an input signal line and an output 
l^nal 1 ne. The converters convert the single ended signals appearing on 
Jese lines to differentia, signals. The differential signals, however, can 
be used as single-ended signals as is known in the art. The first 
e pansion port 104 interfaces the player tracking node 44 with a large 
. a uun, floLcent display 10. (FIO. 5, used to display P'^Ver -.ing 
niessages, as described further helow. The display ^ 
connecter 115. in the preferred enibodiment. by a cable 103. Ihe o h 
expansion ports 106 provides the player tracking module with future 
expansion capabilities to support additional features. 



4 CAKD READER 

. FTPS 6 and 7. the card reader 100 will now be 
-Referring now to tlLrb. t) anu i, ^ 

' - r " : : — ^^^^^^^^^ l..: ... 

pfV^^^nrrl reader IS shown- ihecaraifc^^^ 

at opposite, respective lateral ends of the open.ng 118. The 

Xnd m have stops 126 and 128, respectively. The .u.de ra.ls 122 

and 12 suide the card 120 thro.,h the opening 118 until an end o h 

d 120 contacts stops 126 and 128. The card is shownju, y .nserted .n 
FIGS 7B andVCwith the end of the card 120 abutting the stops 126 128. 
The card reader also includes a printed circuit hoard 130 hav.ng a 

. 1 199 f^nrl 124 to be inserted 

iongitudinal opening to alW the gu.de r. 1- - ^ 

therein in order to allow ^^^^ ^ ,„,IOS. 7B 

flush aeainst a mounting plate 132 ot the Dezei ± , 

!ir,C Mounted on one side of the printed circuit board 130 rs an array 
andTO. Moum .„f„4pf„ctors 136. The photodiodes 

of photodiodes 134 and an array of photodetectors 13 P 

134 are mounted on the printed circuit board ^'-^ ^Y"';!^ 
opening in the printed circuit hoard, while the photodetectors 136 

"L on the printed circuit board along an opposite s>de of the 
Tning ^he Pho^aiodes and the photodetectors are vertically al.gned 
a nttln relationship, i.e., one photodiode for eacb photodetec.r^ 
m a one , ^ ^. . ..^ „rray of photodiodes includes eight 

In the preferred embodiment, the array oi p 

openings in the card 120. as described further 

Jso in ludes optional light nrasKs 138 and 140. The hght mask 18 s 
toltea wit^ the array of photodiodes 134 and has a plurality of 
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openings therein, eachopeningcorrespondingtoa„in<iividualphotoa,oae 
in the array 134. Similarly, light mask 140 is associated with the array 
of photodetectors 136 and also has one opening for each of the 
photodetectors. The light mask 138 is mounted on the printed c.rca.t 
board 130 beneath the array of photodiodes 134 along the opening m the 
printed circuit board 130. The Hght mask 138 is aligned with the 
photodetectors 134 so that the opeuings in the light mask 138 are directly 
beneath a corresponding photodiode in the array. The light mask 138 
minimizes the amount of light emitted by a photodiode that can be 
detected by a photodetector other than the corresponding photodetector. 
The light mask 140 is mounted on top of the photodetector array 136 so 
that the openings therein align with the individual photodetectors. The 
light mask 140 further eliminates extraneous light from the photodiodes 
as well as extraneous ambient ligbt. 

Also mounted on the printed circuit board 130 are a plurality of 
hght-emitting diodes 142, as shown in FIG. 7C in broken line. The hght- 
emitting diodes are mounted on a side of the printed circmt board 
opposite the side on which the photodiodes and photodetectors are 
counted on. The light-emitting diodes 142 are mounted around the 
perimeter of the opening in the printed circuit board 130 and are recerved 
in a recessed portion 144 of the bezel 116. The light-emitting diodes 142 
comprise a means for providing visual feedback to a user inserting a card 
120 into the bezel 116, as described further below. In the preferred 
embodiment, the Ught-emitting diodes 142 are dual light-emitting diodes 
capable of producing two primary colors and a third combination color. 

Referring now to FIG. 6, an electrical schematic of the card reader 
is shown The schematic includes the array of photodiodes 134 disposed 
along one side of the card reader opening 118 and the array of 
photodetectors 136 disposed along the opposite side of the opemng 118. 
„ In the preferred embodiment, there are eight photodiodes and e.ght 



e„„espo„ain. p.otodetectors. The photoaicde. a.e ---^ '^ 
with the two photodioaes within each pair be.ng connected » a ena 
<■ wr. The anode Of the first photodiode in the pa>r,s coupled to the 

:p:;ora:eTh..h..3to.whi.ethe.^^^^^ 

- the T>air is connected to an output of a dnver orcuit 144. The dr 

^^^^^ 

connected in parallel. A signal is prov.ded to the drive 
KT controller 98 over a conductor 146. A signal on conductor 146 causes 
Te d -ver circuit 144 to conduct current and thereh. actuate the 
photodiodes 134 substantially simultaneously. 

The photodetectors 136 are comprised of a plurality of hght 
Pno Theemittersofthephototransistors 
,ensitivephototransistorsPDl-PD8. Iheem.ue 

PBl-PDSareallcoupled to ground. ThecollectorsofphototransistorPm 

and PD8 are connected together and to a conductor 148 "^^^ ^^^^ 
controller 98 senses light detected by either phototrans.stor PDl o PD8^ 
:hltransistorsP..andPO.aresirni,arlyconn.tedwi^^ 

:f re::!,: connected t„ . 

r—r^ rcoLors of the center photot— and 

wever, are : ^:::^:rz:i:::^ . : 

rpqoectively. Also connected to eacn oi u , „ „ 

respective y ,„ ti,. nreferred embodiment, the puUup 

cnrresnonding pullup resistor. In the prelerreo e 

corresponui p»„h of the conductors 148- 

resistors are included in a resistor pack 158. Bach of thee 

156 are connected to a connector 170, which is coupled to the PT 
5 controller 98 as described below. ■ ^ „ pm and 

Based on the above configuration of the P^"- "^'^ 
PD8 only five conductors are required to sample all eight of the 
iristors. Without more information, ^ P.. 

Lclcing controller 98 would be unable to determine which of he w 
3. phototransistors commonly connected to a particular conductor, e.g.. 



conductor 148, detected light. For example, if either phototransistor PDl 
or phototransistor PD8 detect light, the voltage level on conductor 148 
will drop from a high voltage of approximately 5 volts to a low voltage of 
approximately 0.7 volts. Without more information, the player tracking 
controller 98 would be unable to determine which of the two 
phototransistors. PDl or PD8, actually sensed the light. According to the 
invention, however, the card 120, as shown in FIG. 7A, includes a first 
slot 150 by which the PT controller 98 can determine which of the two 
photodetectors detected the light, as described below. 

The card 120 includes five rows of slots 152-160. The rows of slots 
152-160 are arranged in a matrix with the corresponding slot locations 
within each of the rows being aligned in columns. Only the first slot 150 
of row 152 cannot be aUgned with any other slots, i.e., slot 150 is in a 
column all by itself. The individual slots within the rows of slots 152- 
160 encode unique player tracking information. Each slot represents a 
single binary bit in the player tracking information. Either one of two 
conventions can be used to encode the information. First, a slot can 
represent a binary 1 and no slot can represent a binary 0. Second, a slot 
can represent a binary 0 and no slot can represent a binary 1. The player 
tracking information can include: a unique player identification number, 
the casino issuing the card, player membership information, etc. 

In the preferred embodiment, the card includes five rows of slots 
each having a maximum number of nine individual slots, thereby 
producing 45 possible slots. The first row of slots 152. however, is not 
used to encode player tracking information, but instead is used to 
synchronize the sampling of the player tracking information by the player 
tracking controller 98. Thus, only 36 slots are used to encode player 
tracking information in the preferred embodiment. This still allows 2-^6 
possible combinations, which is more than adequate. 



The PT controller 98 uses the first row 152 to synchronize the 
sampling as follows. The PT controller 98 continuously samples the 
outputs of PD4 and PD5 looking for a slot. If a slot is detected on either 
PD4 and PD5 and no other slots are detected by any other 
phototransistors the PT controller 98 determines that the detected slot 
must be slot 150. The PT controller 98 then continuously samples the 
output of the phototransistor that detected slot 150. Once a new slot xs 
detected by that phototransistor, the PT controller 98 then samples the 
outputs of the other phototransistors, i.e.. PD1-PD3 and PD6-PD8. on 
conductors 148. 150 and 152 for slots in of the other rows. Thus, the PT 
controller 98 synchronizes the sampling of the other rows of slots to the 
detection of a slot in the first row 152. 

It is important for the card reader to detect the orientation of the 
card in order to correctly interpret the player identification information 
encoded on the card. The card reader detects the orientation of the card 
120 by detecting the slot 150. If slot 150 is detected by phototransistor 
PD4 then the card reader knows that the card is in the orientation shown 
inFm 7A. In that case, the card reader knows that the player tracking 
information is actually being detected on phototransistors PD5-PD8, and 
can interpret the player tracking information accordingly. If. however, 
phototransistor PD5 detects slot 150. then the card reader knows that the 
card 120 is oriented 180 degrees from that shown in FIG. 7A. In that 
case the card reader knows that the player tracking information is bemg 
dete'ctedby phototransistors PD1-PD4. and can interpret the information 
accordingly. The PT controller 98 can simply transpose the player 
tracking information sensed on conductors 148-152 depending upon the 
detected orientation of the card. Thus, the card reader according to the 
invention is able to correctly interpret the player tracking information 
regardless of how the player inserts the card 120 into the bezel 116 of the 
, card reader. The invention is able to accompUsh this with only five 
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conductors between the eight phototransistors PD1-PD8 and the PT 

controller 98. 

The card reader further includes a plurahty of light-emitting diodes 
142 that are mounted on the printed circuit board 130 and received in the 
recess 144 of the bezel 116, as shown in FIG. 7C. The LEDs 142 are 
xnounted on the printed circuit board 130 so as to surround the card 
reader opening 118 as shown in FIG. 6. In the preferred embodiment, the 
card reader includes 24 dual diodes arranged in pairs. The dual d.odes 
have two separate diodes, each being able to emit a different primary 
color of hght. In the preferred embodiment, the dual diodes emit either 
red or green light. The dual diodes can also emit a third combination 
color if the two individual diodes in the dual diode are actuated 
simultaneously so that the two primary colors combine. In the preferred 
embodiment, this combination color is approximately orange due to the 
differences in the intensities of the red and green light. 

The dual diodes are essentially treated as two individual diodes. 
The red diodes R in the dual diodes are driven by a driver circuit 162. 
while the green diodes G in the dual diodes are driven by another driver 
circuit 164 The driver circuits 162 and 164 are, in the preferred 
embodiment, two open collector drivers connected in parallel, as with 
driver 145. However, other equivalent driver circuits would be apparent 

to those skilled in the art. 

The dual diodes are arranged in pairs with the anodes of one of the 
dual diodes being coupled to the supply voltage .5V and the cathodes of 
the other dual diode being connected to the output of the corresponding 
driver circuit. Accordingly, the red diodes are commonly driven by driver 
circuit 162. which is responsive to a signal received from the PT controller 
98 on conductor 166. Similarly, the green diodes are commonly driven by 
driver circuit 164, which is responsive to a signal received from the PI 
controller 98 on conductor 168. Therefore, the PT controller 98 can 
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selectively actuate the red diodes, the green diodes or both by generating 
the corresponding signals on conductors 166 and 168. 

All of the conductors over which the PT controller communicates 
with the card reader, i.e., 146-156 and 166-168, are connected to a 
connector 170 as shown in FIGS. 6 and 7A. The player tracking module 
44 then includes a cable 172 that is connected between the connector 170 
and the PT controller 98, as shown in FIG. 5. 

Although the preferred embodiment of the card reader is an optical 
card reader, the invention is not limited to such. The lighted bezel can be 
used in conjunction with any form of card reader such as a magnetic card 
reader, a bar code reader, etc. The method of providing visual feedback 
to the player herein described is a general method which can be used with 
a plurality of cards and card readers. 
5. DISPLAY 

Referring now to FIG. 8, a schematic for the display circuit 102 of 
the player tracking module 44 is shown. The circuit 102 includes a 
display controller 174, which in the preferred embodiment is a part 
number HD6473258P10 manufactured by Hitachi of Tokyo, Japan. 
Coupled to the display controller 174 is a memory 176 via bus 178. The 
memory 176, in the preferred embodiment, is a 32KB SRAM. The 
memory 176 stores the variables and parameters necessary for the 
controller 174 to communicate with both the PT controller 98 and the 
display driver 186. The bus 178 includes the necessary address lines, 
data lines and control lines to interface in memory 176. 

In the preferred embodiment, the display 102 includes a vacuum 
fluorescent display (VFD) 184, which is organized as a 16 x 192 display 
matrix. Such displays are well-known in the art of digital electronics. 
The VFD 184 is driven by a driver circuit 186. which includes a plurality 
of individual drivers serially interconnected. In the preferred 
embodiment, these serial drivers are part number UCN5818EPF-1. 
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manufactured by AllegroMicrosystems,Inc.ofWcrcester.Massachusetts^ 
The driver circuit 186 is connected to the VFD 184 by bus 188, wh.ch 
includes 160 individual conductors. The manner in which the 160 bus 
lines are connected between the driver circuit 186 and the WD 184 is 
known in the art, and is therefore not described in detail herern. 

The display controller 174 interfaces with the driver circuit 186 by 
a plurality of signal lines 190. These signal lines transmit the standard 
driver interface signals to the driver circuit 186. These signals include: 
a clock signal CLOCK, serial input data signal SDATA, a frame signal 
FRAME a strobe signal STROBE, two output enable signals OEl/ and 
OE2/ a column clock signal COL CLOCK, and a column output enable 
signal COL OE/. These signals have well known functions in the display 
art and are therefor not discussed in detail. The signal names havmg a 
•■ / " represent active low signals while all other signals are active high. 
The display controller 174 generates these signals in the required 
sequence in order to serially clock the reformatted display data to the 
driver circuit. One of ordinary skill in the art could program the display 
controller 176 to generate these signals in order to display the desired 
message on the VFD 184 based on the foregoing description. 

The display 102 also includes a serial interface 192. The serial 
interface 192 is the means by which the PT controller 98 communicates 
a player tracking message to the display 102. In the preferred 
embodiment, the serial interface 192 includes two opto-isolator circuits: 
one for the serial send data, the other for the serial transmission data. 
The display controller 174 is connected to the serial interface 192 over a 
two conductor serial bus 194, one conductor for receiving serial data from 
the serial interface 192, the other for transmitting serial data thereto, A 
connector 196 is also coupled to the serial interface 192. The connector 
196 includes four terminals. Two of the connector terminals are 
, dedicated to receiving serial input data and the other two terminals are 



dedicated to transmitting serial data. A cable (not shown) couples the 
display 102 to the player traclcing module 44 between connectors 196 
(FIG. 8) and connector 115 (FIG. 5). 

6. DISCRETE INPUT SECTION 
The display 102 further includes a discrete input section 198. The 
discrete input section 198 is an interface between the discrete outputs of 
a gaming device and the display controller 174 much in the same way 
that the discrete machine interface 72 allows the data communication 
node to interface with a gaming device. Although in the preferred 
embodiment the discrete input section is unconnected to any discrete 
machine inputs, the discrete input section 198 allows the display 102 to 
operate as a stand-alone module for gaming devices in certam 
configurations. The discrete input section provides discrete input signals 
from an external device to the display controller 174 over a bus 200. The 
discrete input section 198 includes opto-isolator circuits such as part 
number TLP620 manufactured by Toshiba Corporation of Tokyo, Japan 
which provide single-ended input signals to the display controller 174. 
D PERSONALITY BOARD 

Referring now to FIG. 9, a personality board 202 is shown in 
schematic form. The personality board 202 uniquely identifies the 
gaming device on the network. The personality board 202 indicates the 
type of gaming device, e.g., slot machine or video poker, including the 
manufacturer, and provides a unique machine identification number that 
the host computer can use to uniquely address the gaming device. The 
personality board 202 allows the devices to be readily removed and 
reinstalled in the network without any manual reconfiguration by the 
operator, such as resetting dip switches. 

The personality board 202 couples the data communication node 42 
to a gaming device. The personality board 202 includes two connectors 
204 and 206 and an identification circuit 208. The connector 204 couples 
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to the aata communication node 42. as described further below. The 
connector 206 connects to the particular gaming device. The components 
shown m FIG. 9 are mounted on a printed circuit board that Is mounted 
inside a connector harness (not shown). The personality board allows the 
DON to be easily removed and reinstalled from the network with m.n.mal 

effort. . ^ .... 

The personality board uniquely identifies the maclune by providing 

both a configuration number, which indicates the type of gaming dev.ce 
that is connected to the connector 206 and a unique identification 
number, which is used by the system 10 to maintain records on the 
machine. The configuration number includes a six bit binary number 
which indicates the type of gaming device connected to the personality 
board 202. Each machine type is assigned a unique configuration 
number. This configurationnumberisencodedonlinesCNFG0-CNFG5, 

which are connected to terminals 204Q-204V, respectively, of connector 
204 Each line represents one bit of the binary configuration number. 
The individual lines are either tied to a supply voltage to represent a 
binary one or to ground to represent a binary zero. The six bit 
configuration number used in the preferred embodiment can encode up 

to 2-6 different combinations and. therefore, different machine types. 

The configuration number for the embodiment shown in FIG. 9 is equal 

to3CH. . ^ f 

The configuration lines CNFG0-CNFG5 are coupled to the inputs ot 
parallel to serial converter 86 (FIG. 3) through a connector (not shown). 
The terminals 204Q-204V of connector 204 have corresponding terminals 
85Q-85V of connector 85. as indicated by corresponding lettered suffixes. 
This same lettering convention is used throughout. 

The configuration number is used by the DON controller 46 as a 
means of interpreting the discrete input signals received from the 
,0 machine through connector 206. Individual conductors coupled between 



connector 204 and 206 are labeled to correspond to the machine type 
having a configuration number 3CH. For a different machine type having 
a different configuration number, many of these conductors may have 
different functions. By providing a unique configuration number, the 
DCN controller can interpret the signals received on these lines 
accordingly. 

The personality board 202 also includes an identification circuit 208 
which provides a unique machine identification number to the data 
communication node 42. The unique identification number is stored in 
a nonvolatile memory 210 and provided to a terminal 204N on conductor 
ID. In the preferred embodiment, the nonvolatile memory 210 is a part 
number DS2224 manufactured by Dallas Semiconductor of Dallas, Texas. 
In the preferred embodiment, the nonvolatile memory 210 includes a 32 
bit ROM having a factory-lasered unique serial number stored therein. 
This serial number, i.e.. the machine identification number, can be read 
out of the memory 210 by the DCN controller 46 to uniquely identify the 
machine connected thereto. The protocol for reading the identification 
number out of the memory 210, as is described in the data sheet for the 
part, is well known in the art. 

' The identification circuit 208 includes a number of discrete 
components. The memory 210 has a zener diode 212 coupled across the 
power and ground terminals of 213 and 215 thereof. The identification 
circuit 202 also includes a first diode 214 coupled between the pov.er 
terminal 213 and a data output terminal 217. The circuit 208 further 
includes a second diode 216 coupled between the data output terminal 
217 and the ground terminals 215. A resistor 218 is interposed betv^een 
the data output terminal 217 and the connector terminal 204N. The 
terminal 204N is coupled to a corresponding terminal 74N of connector 
74 (FIG. 4) by a bus 220 (FIG. 2). 



The discrete output, from the machine, e.g., coin in, coin out, etc., 
are also supplied to the data communication node 42 via bus 220. The 
bus220connectsconnector74ofthedatacommunicationnode42andthe 

connector 204 of the personality board 202 such that terminals havm^ 
correspondingletteredsum.esareconnected.F„rexample.termmamC 

of connector 74 is connected to terminal 204C of connector 204 by a 
individualcondactorwithinbus220.AlUheothertenninalsares™.larly 

connected by the bus 220. 

The network interface 49 of the data communication node 42 >s also 
coupled to the personality board by a bus 222. as shown in FIG. 2. Bus 
222 includes four conductors which connects the four temnna.s of 
connector 51 with four corresponding terminals of connector 204 as 
indicated by the common lettered sumxes. It is over these four hnes irat 
the DON controller 46 indirectly communicates with the Hoor controller. 

The serial machine interface 60 is also coupled to the personahty 
hoard 202 by a bus 224, as shown in FIG. 2. The bus 224 includes four 
conductors which couple four terminals 62DD and 62EE of conn ector 62 
with corresponding terminals 204DD and 204EE, respectively. It ,s over 
these four conductors that the DON controller 46 commumcates 
reconfigurationcommands to themachine. TheDCN contro,lertransno,ts 
data through the terminal 204DD, which is provided to the machme on 
conductor MACHINE KX. The machine responds to the conHguration 
command on the conductor MACHINE TX. The use of these two 
conductors will become more apparent in the description of the operat.on 

i hereinbelow. -v ^ 

Although buses 220, 222, 224 and 226 have been descrrbed as 
separate buses, the individual conductors within these buses could and 
are in the preferred embodiment, combined into a single bus that ,s 
connected between the data collection node 42 and the Pe-nah y board 
202 To connect the data collection node 42 and the personahty board 202 



a connector (not shown) is n,ounted on the data col.ecUon node 42 and a 
n^ating connector (not shown) is mounted on the personahty board 202. 
:Hetwoconnector.arethenn.atedtogethertoconnectthedataco„ecUon 

.ode 42 to the personality board 202. The P—J»'^ ^ 
coupled to the corresponding gaming device by a cable 225 (F1G.2). 
E BONUS DISPLAY DRIVERS 

Referring now to FIGS. 10 and 11, two bonus display drivers are 
shown. The data conrn,unication node 42 is designed to supper e.ther of 
the display drivers. The data con,n,unication node 42 is coupled to he 
display driver of FIG. 10 through connector 228. An opto coupler 230 
opt cally isolates the data communication node from a tr.ac c.rcu>t 232 
Jbich includes a triac 234. One terminal of the triac 234 — d o 
a terminal 236B of a connector 236. Another termma, of he r.ac 234 r 
connected to a terminal 236C of connector 236. A bonus - 
a light or sound generating means is coupled across termmals 236B and 

responsive to an actuation signal from the data commun.cafon node 42^ 

A second embodiment of the display driver is shown m FIG. 11. 
thisembodiment,thedatacommunicationnode42iscoupledtothedr.ver 

, o-iR The driver circuit of FIG. 11 mcludes a 
circuit through connector 238. The driver c 

relay 240 operatively coupled to a transistor 242. The relay 240 .s a two- 
position relay which toggles between the two positions responswe o 

. »i, „l, t,,nqiator 242 The transistor 242 conducts a 
current passing through transistor /4Z. ,nmfrom 

current responsive to an actuation signal received on terminal 238B from 
the data communication node 42. „.„ 42 to 

The display drivers are used by the data communication node 42 
activate a display on the gaming device which indicates that the machine 

is now in a bonus mode or condition. 
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F FLOOR CONTROLLER 

. nFTG 1 the floor controller is directly connected to both 

As shown in t lu. i, tne nuu 
the hi.h spaed network 38 and a plurality of gammg dev,ce= The 
the hign speea . •„„ artivitv of each of the gaming 

controller is responsible for monitormg the acUv ty ot 

r— t!r— ^^^^^ 

rnt ^ 

duTng certain honu. conditions. These conditions wiU be described 

eurreluoop networks. Because of the limitations of the current loop 
o:iy . med number of — — ^ ^ 

her of .aming devices, each floor controller .s equipped with 
number of gaming eommunication 

communication board z^o, hmrd 
Wd .40 supports UP to XB separate current loop — - 
is a standard size card that fits into one of the ISA card m 

. u ThP board includes a male edge connector (not 

CPU data, address, and control lines to the communication board 246 ^ 
lable the communication board and the floor controller CPU U> 

communicate. ^.^^^ 

The communication boara ^-io 
microcontrol,ers248A-248H. Tbemicrocontrollerscommunicatew «i be 

floor controller through ISA bus interface logic 247 over 249A and 

;4 B Themicrocontrollersareshowninadaisy-chainconnection inFia 

3„ Tbut any other equivalent interconnection scheme can be used. 



• .a from the Hoor controller microprocessor is passed between 
data recewed from „^ i„^i,,ted by the arrows. Each 

themicrocontrollers from ^48^ to 2 • ^^^^^^^^^^ 

::::rrri:rr::r.ramach^ 
-"Tar— 

.ach— .onercomm— withitsass^^^^^^^^^ 
.,at«ocorrespondin.currentloopnetv,orUs. ~- J 

— n—rr ::::::: — - - — - 

corresponding pair of current loop Unes 263. ^^^^ 

rsrarb::r:ret::uoopdri.ercirc.t.ocan^^ 

the communication board by a ^^"^^ „,„„er 248H is solely 

,n the preferred -""^.'-"^' ^^^f;^", n,icroprocessor. 
responsible for communicatmg w,th the floor co ^ 

A,, of the data received from the ^^^^^ ^^C^^^^L associated 
„ net.orKsarepa3seda,onstothem,crocon rol^er^ H^^^ 

microcontroller. The "'-""^f /^^^^J^L.ted to the Hoor 

— "Tnrre::::::— ^ 

controller. If not, the last Thi^ helps off-load some 

doesnotforwardthedatatothe^— - 
Of the floor controller communication processi g 
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n. OPERATION 

The above-described system allows a casino in which the system is 

installed to run promotions on any properly equipped gan>ing mach.nes 
whilesimultaneouslygatheringplayertrackingandaccountingdatafrom 

all machines. The system provides the capability for the casino to select 
which of the plurality of machines are used in any given promot.on. The 
system further allows any number of different promotions to operate 
simultaneously. 

Each promotion involves sending a reconHguratron command from 
the floor controller to a gaming device that has been selected to be part 
of a given promotion over the associated network. Upon receipt of the 
reconnguration command, the gaming device reconfigures its payout 
schedule in accordance with the received reconfiguration command. As 
described above, reconfiguring a gaming device payout schedule, in the 
preferred embodiment, includes activating a bonus payout schedule that 
pays out bonus amounts in addition to the amount determined by the 

device payout table. 

A partial list of the promotions according to the invention mclude. 

but are not limited to: a multiple jackpot wherein the gaming device 
reconfigures its payout to be a multiple of its default payout schedule; a 
bonusjackpotwhereinthegamingdevicereconfiguresitspayoutschedule 

to payout an additional bonus amount when certain conditions are met; 
and a progressive jackpot wherein two or more gaming devrces are 
combined In a progressive jackpot having a progressive jackpot payout 
schedule. In addition to these, many other promotions are possible by the 
above-described system for controlling and monitoring a plurahty of 
gaming devices. 

The system 10 also allows for improved player trackmg. A=, w.th 
standard player tracking, the above-described system monitors and 
reports how many coins are played by each player. The system 10, 



30 

37 



however, also deludes the ability to record how long each player spend 
at each machine and the number of coins won. games played, and hand 
iackpots won by each player. All this information is stored on the 
datale, which can he later analysed for future targeted direct maUmg 
campaigns. The player tracking according to the invention also al low 
the casino to schedule buses and other groups and measure the.r 
profitability. Thesystemalsoallowsforcashlessplayas well asadvanced 

accounting and security features. 

Another feature of the above-described system is jackpot 
announcements. The jackpot announcement feature displays a message 
on a reader board or display located in the casino which announces a 
jackpot as soon as a jackpot is won. i.e.. as soon as the reels stop sprnmng^ 
The floor controller generates the jackpot announcement once a DCN 
connected thereto indicates a jackpot is won. An --^'^ 
message might be: "Now paying on machine 1342. a jackpot o $300. 
With prior art data collection systems, the amount of the jackpot rs only 
known after the payment is made. Kven then the system must account 
for partial pays, hopper empty, etc. ^ the 

An advantage of the current system over pr.or art systems .s the 
ability to implement better tournament systems. In a slot tou— 
players pay a fee to play. All play during the sess.on .s free. The players 
accumulate credits instead of cash. The person with the most cred.ts at 
the end of the tournament wins. Games are usually manually altered to 
provide payouts of 200 to 300% to make the games more tun. The games 
, are altered manually by replacing the read only memory (ROM) in the 

gaming devices. . u 

f «f tnnrnament play is to see who is ahead. No 
One exciting aspect ot tournameni. vi^y 

current system can display this information in real time. This is because 
current systems can only measure winnings as they are added to the 
credit meter or paid from the hopper (some casinos use tournament 
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. • Since credits are usually added at a rate of 10 per 

tokens instead), omce cie-a OoG^T^r.^ 

J-. • .nr. take 100 seconds to register. Casinos 

attempting to create display invention allows 

, 1 ^ The iackpot announcement of the invenuoi 

r«:;— ^^^^ 

«nd firmware routines are described beiow. , . i/i 

rr elence to acco™pan..n. flow charts. These flow charts wou d 
:lleoro.a.na.sKUnntheartofco.pu.e.p— >n.^^^^^^^^^^ 
acortespondin.co»puterp«g«n.whichthecon>putero.™c™cont™ner 
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could execute. 
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L execute. 

A. DATA COMMUNICATION NODE 
1 POWER UP PROCEDURE 

. T.Tr 13 a rower up procedure 252 for the data 
Referring now to FIG. 13. ^^^^ J^^^^ 

communication node is shown. This proce ^^^^^^^^ 

controller 46 when initially powered up. The first step P 
- . .l^clate the RAM to ensure that it is not corrupted and to set up a 
xs to validate the RAM ^ ^^^^j.^.^riting known patterns 

the DCN hardware. Validating the Kmvin , . ^ .i^p 

If is and OS to the DCN RAM. TMs KAM can either be 

DCN cont.one. 42 o. externa, as shown in FIG. 2. Sett.n. up the BCN 

hardware includes initialiring timers and interrupts. 

into an endless loop in 256. 
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o READING UNIQUE IDENTIFICATION NUMBER 

If the RAM is fully functional, the DCN then reads the un..ue 
If the personality board. As described above. 

tWsu„.que.denUf«at,on n ^^^^^^ 

on the personaMy ^-^ ^^^ „ manufacturers 

„onvo>atne — y " ^ ^^^^J^,,,,,, „ aaU sheet. TWe 

^^^^^^^ 

^X^r:.ue ™ has heeu .eaa f.™ the 

the discrete machine inputs m step 260. This step w 
DCN processes the discrete MONITORING GAMING DEVICE 

described in further detail in S"''-^'"'";- "^^^ i„ 

DISCRETE INPUT heiow. *^ ^^t^^^^^^ .,ep 262. 

— E. re:r 

*^v,^ ?r^»-Prface between the DOJN ana uit. 
interface . e., the — ,,,,,,,,, 

connected thereto. ^'"''7;^ j,,„oKK INTERFACE. Finally. 

furtherbelowinSubsectionS.PROCESSmGl Thisstepis 

, theDCNproeessesthepIayertrac....^^^^^^^^^^ 

r~rNrro — de^e 0™ in^^t 

Keferrin. no. to .IG. U, the DON -^-^^^2:1^ 
. ■ tc, 9fin will now be described. 1 he nrfab 
device discrete inputs 260 v,Ul no ^^^.^^^^^ 

discrete inputs on input hues 76 m step 

discrete inputs is shown in FIGS. 4 an 9 for ^ ^ ,3 

The actual discrete inputs present will depend on he mach^ JP ■ 
Indicated hy the configuration number, which is also read hy 
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eontroner 46. Most gaming devices provide at least some of the fcAlowing 
t ™ins in coins out, coins to drop, games played, attendant 
aiscreternputs. "'^ ^^o, door progressive iackpots. and bill 
paid jackpots, slot door, j'" ^ ^j^^.^,, i„p,t, well as 

validators. The system supports all ot these Q 

"'"^The DCN keeps track of the machine activity hy maintaining 

ITach meter in the preferred embodiment, 

3e eral ~ C^^^^ ,e reliability of the system, 

— Inda. back„P copies of these meters with a 
Zer to replace the original meters in the event that the or.gmals e 
corrupted. lnstep268,theDCNi„creme„tsthemetersasre.u,redbas^^^^ 

n th discrete inputs. The meters are maintained even m the evenUh 
the DCN is disconnected from the floor controller. Once the DON s 
lilted to the floor controller, all the activity level information is 
then available. Step 268 will be discussed further below^ 

Next the DCN processes the drop door signal m step 270. The 

aoorstaiDROPDOORindicatesthatthedropdoorouthemachmeha 

biripened. This is an important event and is therefore processed 

separately^ ^^^^ ^„ 

In step 272, tne uv. checks 
whether the values stored in the meters are v id. The 
whether the meter values are vahd m step 274. he p 

embodiment, a check sum is maintained for each meter ^^^'^- J^2l 
DCN in step 274 checks to see whether the check sum is correctbased on 
. rh'—etervalue. "-meter values are okay, the di—^ 
monitoring S..P 260 is compleU.. If the meter va ues are not vah the 
DCN replaces the meter values with the redundant back copy 
meter values in step 278, and then the step 260 is complete. 

Keferring now to FIG. 15, increment meter step 26 is show - 
further detail. The sequence shown in FIG. 16 is repeated for each meter 



,alue*athasc.a„ged.Ther.ststepistoaaiustt.en,ete.va,ueba 

on the discrete inputs and to calculate the associated check sun,. N .t 
tL DCN detennines whether the particular n>eter has an act„e 
tsLiated countdown count in step 282. Son,e .a,nes or pron,ot.ona. 
allies require the player to reach a certain level oE activity .„ order o 
he Uiible Jr certain bonus points. These countdown counts are used to 
d t rLe whether the player has achieved this level of a« Fo 

e.an,p.e, the player nray he -f-:::::^::^:::^^ 

before being awarded any points. If the countdow 

DCN adjusts the current players count down values ,n step 284 

the corresponding adjustment of the associated meter. 

message The count down message indicates to the player when he or she 

ed to the .ayer ...... 

ZTL processing, as described further below. The — 
indicates the be.el color and the count down rate md.cates that flashmg 
„te of the bezel color displayed during the count down message. 

4 PROCESSING GAMING DEVICE SERIAL INTERFACE 

Keferring now to FIG. 16, a process 262 for processing the gammg 
device serial interface is shown. The serial machine --^^ - 
.hown in FIG. 2, allows the BCN controller 4B to com— w.h^h^ 
earning device through the personality board. This sena, 
nT Ice allows the DCN controller 46 to transmit reconfiguration 
' etmaTds to the gaming device in order to reconfigure the payout 
rcreduleofthemachineinaccordancewiththereconfigurationcommand^ 

addition,theseria.machineinterfacepr„videsanadditiona.m^^^^^^^^^^ 

determining the activity level of the gaming device. ^"^^'^'^^'^^ ^^^^ 
3„ the discrete machine inputs, the DCN controller 46 can transmit a 



.e,uest _„a to the ™cMne ove. the serial interface ana the 
Jach.ecan.esp.ahaeU..hthe.,ue^ast— 

rthri— ^^^^^^^ 

— — r: lucK P-co, uses a aata PaCet — a 
art. An example ^ rT(C and a variable 

A r.A. » message sequence number, a CKU, ana a 
command code, a messag ^ ,;,ber the DCN controller 

Tr. fV.p ^referred embodiment, either tne uy.i^ 
length message. In the preterr « ^^er the serial machine 

or, iTiitiate communications over tne send 

— the — .u. a^o. .ts ^.a^e ana 

attempt to resend the message at a later time. 

, ^- f ffi.p Qv^item supports many different 
The preferred embodiment of t^^^^^^^^^^^^ PP^^ _„ion 

reconnguration command. ^ ^^^^^^^ reconnguration commands 
commands is given b^ow in^^ a^^^^^ 46 to the machine over the serial 
are sent from the DCN controlle ^^^^^^^^ 

xnachine interface wherein the machine reconfigures its p y 

. with the particular reconfiguration command. The 

in accordance with the pa .^^^^^^ 

reconfiguration commands do not originate wi 

reconiigui - • from the floor controller and are 

-Tat rz"::::" - —a ....t 

transmitted to a parucuia computers on 

— - - — r ;:;cr;:;; — ^^^^^ — - 

the high speed network. The DUiN is bi p j' • . tv,*. 

the hign sp gaming device on receipt of the 

the reconfiguration command onto the gam g ^^^^^ 

reconfiguration command over the associated current 

, coupled between the floor controller and the DCN. 

Table 1 - Examples of Reconfiguration Commands 
Bonus Pay From Hopper (Coin Format) 
lonus Pay to Credit Meter (Coin Format) 
Bonus Pay from Hopper (Dollar Format) 
Bonus Pa^ To Credit Meter (Dollar Format) 



1. 

2. 
3. 
4. 
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5. Add Non-cash outable credits to Game 
6 Begin Double Jackpot Time 
7. Stop Double Jackpot Time 

TheaclualprocessofprocessingthemachineseriaHnterracebegin. 
in step 292 wherein the DON polls the machine to determine its level of 
activity This polling step includes sending a status message from the 
DCN to the machine over the serial machine interface. In response, the 
machine will send a packet of status information indicating the current 
amount of activity on the machine. The status information included m 
the response will depend on the type of machine that the DCN ,s 

communication with. 

The data communication node 42, in step 294, waits for a reply to 
the status request. If a reply is received, the DCN indicates that the 
machine is "on line" in step 296 and processes the machine reply m 298. 
The step of processing the machine reply ir>cludes updating the meter 
values, as done when processing the discrete inputs. After the machme 
reply has been processed, the process 262 is complete. 

If the DCN does not receive a reply from the machine m step 294, 
the DCN indicates that the machine is "offline". The DCN will wait for 
a predetermined amount of time before deciding that the reply is not 
received. In the preferred embodiment, this predetermined penod xs 

approximately 110 milliseconds. 

5 PEOCESSING NETWORK INTERFACE 

Another step in the DCN power up procedure 262 is the step of 
processing the network interface 264. This step is described w>th 
reference to FIGS. 17-19. The network interface refers to the current loop 
that connects the particular DCN with the associated floor controller 
The following description assumes that the DCN has received a vahd 
, message from the associated floor controller. Because there are mult.ple 
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^r.i InoD the floor controller must include 
DCNs connected to any one current loop, the 

-----r:::— ^^^^ 

,op, . . - : a Ja „u.b« or OCNs connected to 

^^^^^^^ 

,He DCN. — iaentification nun^ber ^^^^^f ^ 

^"^^^^":ro: rlt .op netwo... m t.e p.ere„ea 

be supported on any g>ve ^^^^^^^^^ ^ ^ 

e„>bodiment. however, only 64 ° .aequate. 

current loop and therefore the smgle byte address 
Xhes^n^lebyteaddresssubstantlallyreaucesthea™^^^^^^^^^^ 

— >oop networU by redu^ns -- "-^-^^^^^^ 

unique identification number to one 

■^"^^rrr controller is responsible for .eneratln, the unl,ue sln.le 

. byte :Lss for each data 

network. The process of assigmng unique single Dy 
DCNs is described below in Section C. 

once all the DCNs have been assigned a unique address, the DON 
» the current loop network for messages addressed to 
can begin monxtormg the current p 

it If the DON detects a message addressed to it, the DOIN 
^' .64 The DCN fxrst checks to see whether the message is vahd rn step 
264. ineuoix rTRP value of the message and 

304. This check is done by computmg the CRC value of 

. ► rt,„ TRr included with the message. It the two 
comparmg .t to the "> p„cesses the network message 

match, the message .s ^^^^ ^^ '^^^^J^^^^ ,„.,ber below 

in Step 306. Processing the networ.^ 
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«Hh.eferencetoFIGS. Wand 19. Once the message has been processed 
the DCN sends a reply bacU to the floor controller over the current loop 
„etworMnstep308. Theactualsuhstanceofthereplyw laepen^^^^^^ 

„,essage received in step 306. If the message .s mvahd, the DCN 

Referring now to FIG. 18, the first step of processing the network 
message is to determine what type of message was sent from the floor 
TntroL in step 31.. There are three basic types of messages ha^ he 
floor controller sends to the DCN. The first is a request for 
BCN If this type of message is detected the DCN bmlds he data 
r.uested and transmits the data in a reply message. The mam use o 
tJs message type is to gather status and meter informat.on from the 

°™Anothertypeofmessageisoneincludingco„r,gurationdataforthe 
OCN. This message allows the floor controller to implic.t.y set he DCN s 
„,emory to a fixed value. This message is used to overr.de the DCN s 
Tntern:! variables, e.g., to get a DCN out of a lock-up — ; ; 
download new firmware to the DCN for execution. On rece.vmg th,s type 
ofmessage.theDCNsimplyoverwritesitsmemon-withtheconfig— 

data included in the configuration message in step 16^ The DCN then 
builds an appropriate acknowledgment and transmits th.s 
acknowledgment message to the floor controller in step 320. 

The other type of message is one sent in response to a DCN request. 
The DCN processes this data in step 318, which is described further m 

• 1 ^^c^^Uhpr the configuration data or the data 
FIG 19 Ifthe message includes either tnecoiuifi 

i„ response to a DCN request, the DCN builds an acknowledge message 

in step 320 and transmits this message to the floor controller. 

Thestepofprocessingafloorcontrollermessagesentmresponseto 

aDCNrequestwiflnowbedescribed with reference to FIG. 19. The firs 
3, t!pofprcessingthistypeofmessageisfortheDCNtodetemunewhat 



t,p. of data is included in the ..essage. Once again there are three types 
Tdata that can be included in this n.es.age type: a reconfi^ra >o„ 
cLand. card data, or other «inor data. The DON r^aUes th.s 
:e:er™in:tionin3tep324hyana,y.insoneofthehytes«thedatapac.et 

of the message. This byte will be referred to herein as the command byte. 
:f:h:commandhyteindicatesthatthemessagecontainsreconfi^rat.n 

data ie the command byte equals a reconfiguration command, the DON 
storls the reconfiguration data in a predefined data structure in memory^ 
Listed below in Table 2 is an example of a data structure for stormg the 
reconfiguration data. 

Table 2 - Reconfiguration Data Structure 

1. Bonus Type 

2 Mystery Jackpot Data: 

A. Number of coins to award 

B. Number of seconds to award 

C. Pay award to 

3 Bonus Time Data 

A. Jackpot Multiplier 

u Tarkoot Payout Limitations 

C. Number of Seconds to Keep Bonus Time Active 

D. Minimum Activity Level 

The bonus type field of the data structure indicates the type of 
bonus state the machine is U, be placed in. Examples of potential bonus 
modes include progressive/nonprogressive, multiple iacUpot, or mystery 
iackpot. It the mystery JacKpot is indicated, the mystery i^^^"' ^^^^ 
included in the structure specifies the conditions under wh.ch the 
mystery iackpot is paid out. The mystery jackpot can be set to payout 
. Z. aftl' a certain number of coins in. handle pulls, which .s specified by 
subflelds of the mystery jackpot data. 

The bonus time jackpot is a promotion wherein the machme pays 
out more than that dictated by its default payout schedule. In one 
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. f th. bonus time promotion, the payout schedule of the 

machme can oe uiu Thiq oromotion canbe 

v,f- 1^ CA^ nf the bonus time data, ims proiuuui 

used to encourage g promotion can be 

,4a.n..on.ee.n.gH- ^^^J^^ iac.pot is 

specRed by the ca= ^^^^^ ^^^.^^^ p,^^^ 

The bonus t,me data also speci es „.3„bfield(B) of the bonus 

^con>es eligible for the bonus '-^-".^"'^^ ^'^^^'^"^^^^ ^ata 
time data specifies whether the player ,s ^'^^'^'^^^^^^ 3^,,,,,, 
onlyifthep,ayerisp,ayingthema_com n^^^^^^^^^^^ ^^^^^^ 

rr^ limits the bonus time promotion to a preaet 

r This field limits the bonus time promotion to a predetermined 
seconds. This field 1 ^ .^^^^^^ ^.^^^.^ ^^^^ 

number of seconds, if the player The minimum 

.Hfied time period, the bonus time promotion concludes. The m 
specified time pen , ur i/l This field can be used 

activity level can also be spedf.ed m subfield (D). Th s 
to specify the minimum activity level reqmred by the ^ay 
be elirible for the bonus time jackpot. For example, the player 

d lo Play at least 20 coins over the last three minutes m order to 
required to play at least «„ indicator hght on the player's 

- eligible for the bonus '^^X:^ «-es the minimum 
wrirrerXtl^es eligible for the bonus time .ckpot. 
In another embodiment of the bonus time promotion, a bonus 
amount is aided in addition to the payout according to the defaul of 
amount IS awa The amount of the bonus jackpot is 

„ the payout schedule of the machine. The amoun ^^^^^ 
specif,edinsubrield(E)ofthe bonus timedata. Fore. p 

•r.>.t inrlude five bonus amounts of $10, 
^"^^"'""^rf i:^!: by subfield (E). When a player hits a 
and $500. , specified by the bonus 

particular jackpot, whichever addition to the 

amount subfield this amount is automatically paid out in 



30 

48 



10 CO 



15 



20 



payout an>ou„t dete^ined by the machine-s default payout scheduK 
Thisbonusttaepron.otioncanalsobeu.edinco.binatt„nw.tHsuba^^^^^^^ 

(C, and (D, to specify the conditions under which the player . ehg.bie for 
this bonus time jaclcpot award. qofi the 

After the DON has stored the reconfiguration data .n step 326, he 
DON win then send the appropriate reconfiguration conunand to the 
n^achine over the serial machine interface in step 328. The n,ach,„e 
responsive to the received reconfiguration command, reconf^ures rts 
payout schedule in accordance with the received reconfiguratron 
coLand. For example, if the reconfiguration command specfies a 
::.tiple iaCpot condition, the machine will reconf.gure its payout to be 
a multiple of its default payout schedule. The machine wdl reconfigure 
its payout schedule in a similar roanner for the other bonus type. 

The other type of data that can be included in a response rem a 
DON request is card data or player tracking data. This data is sent to he 
DCNin response toastatusmessagefromtheDCN to thefloorcontroller 

wherein the status message indicates that a player card has been 
Tnserted. Included in this message is the card ID number detecte by th 
card reader. In response to this status message the floor controller w.U 
transmit a card insertion message to the DON. The card msertr n 
Message includes information associated with the particular player ID 
lumber. An exemplary card insertion message data packet .s hsted 
below in Table 3. 
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TABLE 3 - Card Insertion Message Data Packet 
1 Card Identification Number 
2 . Player First N ame 
3 Player Last Name 

4. Current Point Balance 

5. Casino Code 
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upon receipt of the card insertion message, the DCN stores the 
piayer-s nan^e and points in order for this inroonation - » 
he WD display associated «ith the pia.er tracMns node. T en,^ DCN 
.ets the current message to a data received rr,essage m step 334 «, 
a DCN sets the current be.e, color and he.e. rate to a data — d W 
:Z and he.e, rate in step 336. The be.e, coior specifies the he.e, coior 
tohedisplayedhythecardreaderandthebe.eiratespecir,estheflash.n 

rate of the card reader LEDs. This bezel information .s subsequently 
transmitted to the player tracking node for processing thereby. 

The fma, data type that can be included in the message sent from 
the floor controller in response to a DCN request is generically c ass^fied 
Is other minor data. This data includes general system or DCN spectfic 

information such as display information. 

6 PROCESSING PlAVER TRACKING INTERFACE 

The next step in the DCN process is processing of the player 
tracking interface 266. The DCN maintains a variable that indicates 
It message is to be sent to the player tracking node. This vana le .s 
referred to as the current message variable. Before transmitting a 
message to the player tracking node, the DCN first '^^'^^^"^ 
. to see which of a plurality of messages should be sent to the player 

tracking node. „«4-«fVif> 
Theprocess 266 beginsin340by sending thecurrentmessagetothe 

player tracking node that is specified by the current message var.able^ 
A ddition to the current message, the DCN sends the be.e color and 
bezel rate information to the player tracking node. The bezel color and 
bezel rate information could have been specified by the noor controller or 

" Ne'tTDCN determines the card status in step 342., If there is 
no card inlerted in the card reader, the DCN sets the 
3„ variable to an attract message. This message specifies that the player 

50 
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,„e.ing node is to disp.a, a n>essa.e wMch .... . ct P'-J 
™cM„e. Si^Uariy, the DON sets tbe current be.e. color and beze. ra^ 

to an attract be.el co.or and rate in step 346. Tbis attract color and ra^ 
■:partoftbeattractn>essa.etbatwmbesenttotbeplayertrac.rn.node 

wben tbe current message is sent. 

If tbe DCN determines tbat a good card has been .nserted ,n the 
card reader, the DCN processes the valid card in step 350. This step .s 
described further below with reference to FIG. 21. 

If however, tbe card status indicates that a bad card has been 

inser^d i e., an invalid card number, tbe DCN sets the current message 
mseriea, i.e., 

variable to specify a card error .nessage m 352 and DO 
current be.e. color and bezel ra.. to a card error color and rate .n 5^ 
This card error information is included with the card error message that 
i. sent to the player tracking node when the current message ,s sent. 
7 PROCESSING CARD INSERTION 

Referring now to FIG. 21. the process 350 for processing a valid card 
insertion is shown. The first step that the DCN executes is to determme 
wt ther the card data corresponding to tbe vaUd card has been received 

„ ■ I -.Kfi If not the DCN builds a network 
from the floor controller m step 356. If not. the u 

request message for tbe player name and points associated w.th tW^rd 
ID number in step 358. Next, the DCN sets tbe current message ar,able 
to specify a card inserted message is to be transmitted m step 3 0^ 

Ir d rate, which indicates to the player that the system ts strll 
. processing the card number. This information is sent to tbe player 
tracking node wben the current message is sent^ ^ 

If the card data has been received from the floor controller, the DCN 
.ben determines In step 366 whether player ^7';*^;:^ 
particular player. If player trackinghas notyet started, the DCN s^ be 
30 Lrrent message variable to tbe data received message m step 
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sets the current bezel color and rate to data received color and rate m step 
370 If player tracking has started, the DON processes the player 
tracking in step 372, as described with reference to FIG. 22. 

Processing player tracking 372 begins with the step of detemnn.ng 
whether the player has received ne. points in 374. These points can be 
considered roughly as the equivalent of -frequent flyer ra.^es used by 
airlines. These points allow the system to run promotionals whereby 
individuals are given points or credit associated with their card tha can 
be redeemed toward the purchase of goods or services offered by the 
casino. Typically these points are redeemed at a redemption counter m 
the casino for meals or clothing, for example. The points, therefore, are 
an additional inducement to encourage play. 

The player tracking system of the invention allows the casmo to 
determine how and when the player is issued points. T^he casino can 
specify the type and number of coins that must be played before a player 
is awarded a given number of points. The system uses th,s specHed 
information to inform the player of his or her progress towards rece.v.ng 
add.tional points. The system encourages play by info.™ing the player 
of how many additional coins must he played before receiving add.t.onal 
points. For example, a player who is only one coin away from rece.vmg 
points, but who desires to stop playing, may decide to play "one last com 
in order to receive the points. The system informs the player by 
displaying a message on the vacuum florescent display indicating how 
many coins the player is away from receiving additional pomts. 

Referring now to FIG. 22, player tracking 372 begins with the step 
of determining whether the player has received new points in 374. If no 
new points have been received, the DON sets the current message 
variable to specify a countdown message in step 376 and sets the current 
bezel color and bezel rate to a countdown bezel color and rate m step 378. 
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The countdo™ bezel color and rate indicates the player's progress 
towards being awarded additional points. ^.e nlaver has 

If new points have been received, such as where the player 

i-u^ nrisT c;pts the current message 
nlayed a given number of coins, the DON sets tn 
vanahle to a points won message in step 382 and sets the current bezel 
CO,:: and rate to a points won color and ra. in step 384. The points won 
message informs the player of the number of points won. 

The above-described tracking process provides a means for 
providing visual feedback to the player inserting the card into the card 

j-f • « fi.^. hpzel color and bezel rate, the data 
reader By modifying the bezel coiui 

rmmunicaln node provides immediate feedback to t e playe 
concerning the proper insertion of the card. H the player inserts th card 
p.operly into the card reader so that the card reader senses a d u « 
Lntirication number, the card reader provides positive -"^^^f-*-^ 
to the user by illuminating the bezel. On the other hand, f the 
improperly inserts the card so that the card reader cannot read the user 
Tenti^ication number, the card reader can provide negative visual 
e ack to the player by illuminating the bezel with a different color 
llor flashing rate. In the preferred embodiment, this posi.ve v.ua, 
feedback includes flashing the green ..Os to ^^^^ 
signal around the card reader openmg. the negative 
ncludes flashing the red LEDs. Athird combination color is used during 
r processing of the player tracking information. This P— v.des 
immediate feedback to the player concerning the insertion of the card m 



25 the card reader. 

B. PLAYER TRACKING MODULE 
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The system described above allows for improved player tracking by 
recording each and eve., machine transaction including: P'^^' 
:achinenumber.durationofplay.coinsin.coinsout,handp^^^^^^^^^^^^^^ 

and games played. The player tracking is conducted over 



network as the accounting data is extracted. This allows the .„vent.on to 
;„.ide bonusing to certain indWidual players as well as d„r.„g cer..>n 
Les As with standard player tracking, the above-descr.bed system 
llitors and reports how .any coins are played by each player ^ The 
system according to the invention, however, also includes the ab,hty to 
rlord how long each player spends at each machine and the nur^^er o 
coins won, games played, and hand jackpots won by each player. The 
is able to record all this information because the it operates on a 
t Iction by transaction basis. Each transaction, whether >t be a com 
„ a h ndle puU, etc., is recorded by the system. Other prior art systems 
mplycompiletheplayertrackinginformationatthecompleuonofplay^ 

AH the transaction information is stored on the database, whrch can 
be later analyzed tor future targeted direct mailing campaigns^ The 
p a er tracking according to the invention allows the casino to schedrde 
buses and other groups and measure their profitability. Because the 
records each transaction, the casino can reconfigure therr casmos 
to better match the tastes and demands of their customers. 

the improved player tracking according to the invention also allows 
.hecasinotocalculatetheoreticalwinsexactlybecausethesystemaway^^ 

includes the most current information. The operatron of the player 
tracking procedure is described below. 

1 Power Up procedure 
The operation of the player tracking module will now be described 
with reference to .IG. 23 where the powerup process 400 for the p layer 
, tracking node is shown. As in the data commun.cat.on j'^^ 
tracking node first validates theRAM and sets up .ts assoc.ated hardware 

step .0. Ne.t, the player tracking node tests the KAM m s.P 04 
determine whether the RAM is functioning properly. If not, the player 
rackingn„de,i.e.,playertrackingcontrol.er,termin— ^^^^ 

^•f^nn m Step 406. If the player tracking RAM is tuiiy 
30 an error condition m step 'tuu. 
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functional, the player tracing node sequentially executes steps 408-414. 
I„ step 408 the player tracMn. controller processes the DCN .n^rf ce 
between the player tracking controller and the DCN controller. In step 
410 the player tracking controller updates the player track.ng d.splay. 
In step 412 the player tracking controller updates the he.el. Finally, the 
plyer tracking controller processes the card reader in step 414., Each of 
these steps will now be described further below. 

2 PR0CK3SING DCN INTERFACE 
ReferriugnowtoFIG.24,thestepsforprocessingtheDCN interface 

are shown. First, theplayertracking controller checksforanewn>essage 
received from the DCN in step 416. If a new message has been rece.ved^ 
the player tracking controller overwrites its current message buffer wrth 
the ne^ message and updates the be.el color and rate values wrth those 
contained in the new current message. Then, the player trackmg 
controller builds a card status reply message in step 420. The car sta u 
ruessage indicates whether a card has been inserted and .f so wbethe th 
card was a good card or a bad card. i.e.. the card was read properly by the 
card reader. Ita valid card, the card status reply message also mc udes 
the identification number encoded on the card. This step m,ght a so 
involve transposing the number encoded on the card dependmg on the 
orientation in which the card was inserted into the card reader. Th.s card 
status reply message in then sent to the DCN in step 422. 
3 PROCESSING DISPLAY UPDATE 
The process of updating the player tracking display is shown in FIG. 
26 at 410 This process begins with the player tracking controller 
scanning the display message for display attribuU information. 
Examples of such display attribute information is gwen below m Table 4. 
Each display attribute specifies a different graphic mode for the player 
tracking display. 
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TABLE 4 - DISPIAY ATTRIBUTE INFORMATION 

1. Flash Rate 

2. Center Display 

3. Set Display Intensity 
4 Use Small Lower Font 
5' Use Small Upper Font 

6. Use Normal Large Font 

7. Set Pause Time 

8. Set Scroll Speed 
9 Center and Melt 

10. Center and Scroll Down 

11. Center and Scroll Up 

12. Scroll Down and Stop 
1 ^ Scroll UP and Stop 

14. Scroll Left and Stop and End of Message 

15. Scroll Down 

16. Scroll Up 

17. Scroll Right 

18. Scroll Left 

19. Reverse Video 

20. Normal 

The player tracking controller then determines whether any such 
attribute information is found in the display message. If so, the player 
tracking controller sets up the display driver to incorporate the graphics 
mode specified by the attribute information. The player trackmg 
controller then strips out any display attribute information fron. the 
display message in step 482 because the display attribute informatxon xs 
embedded in the display message. The remaining data in the display 
message is the actual text to be displayed by the player tracking display, 
e g the player's name. The player tracking controller then sends th.s 
text to the display in step 434, which is then displayed by the player 

tracking display. 

4 PROCESSING BEZEL UPDATE 

The player tracking node is also responsible for updating the bezel, 
both in terms of its color and flashing rate. This process 412 is shown m 
FIG 26 The first step in processing the bezel update is to determme to 



W color as specified by the DON and then drive the approbate LEDs 
I the card reader. As described above, the preferred en.bod.»ent of the 
card reader includes dual diodes having two prin,ary colored d.odes tha 
can be driven separately or in con>bination to produce three d.tferent 

Next, the process determines the be.el rate as specified by the DON. 
in a first case, the bezel rate is zero or off and thus the player track.ng 
controller turns the LEDs off in step 442 in this case. If the bezel rate 
specifies a flashing rate, the player tracking controller fiashes the bez 
at the appropriate bezel rate in step 442. Flashing the bezel .nvolve 
turning the LEDs on and off at the specified rate. Th,s can be 
accomplished by a timer interrupter a timing loop executed by the player 
tracking controller. The final option is that the rate can be mfin.te or 
effectively a solid bezel color. In this case, the player tracking con troner 

J T T7no nr. in step 446. This completes the 
simply leaves the card reader LEDs on m step ^ 

processing bezel update process 412. 

5 PROCESSING CARD READER 

The next process step for the player tracking node is to process the 
card reader. This process 414 is shown in FIG. 27. The ^ " 

the player tracking controller to determine the card status m 450. In he 
preferred embodiment, the card status is determined by eompar.ng the 
checksum of the card, as read off the card by the card reader, to a 
computed checksum of the data read off the card. Other methods f 
determining card status can be used as well depending on the type of card 

5 reader employed. 

If the player tracking controller determines that a vahd card was 
inserted in the card reader, the player tracking controller sets a card 
status variable e,ual to good card. This card status Is then -bsequen y 
transmitted to the DON controller. Then, the player trackmg contr„ner 
sets a card ID variable equal to the identification number read by the 
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card reader in step 454. The card status and the card ID provide the 
DCN with sufficient information to instigate the player tracking. 

If on the other hand, the card reader indicates that the card was 
read improperly or that the card is an invalid card for the card reader, the 
player tracking controller sets the card status variable to bad card in step 
458 and the card ID variable is cleared in step 460. If neither a valid or 
invalid card condition was detected in 450. the player tracking controller 
sets the card status variable to no card in step 462 and clears out the card 

ID in 460. 

C. FLOOR CONTROLLER 

1. POWER Up Procedure 

Referring now to FIGS. 28-32. the process 464 operable on the floor 
controller will now be described. The process 464 is shown in FIGS. 28- 
32 in flow chart forms. These flow charts would enable one of ordinary 
skill in the art to implement the process in computer software using an 
appropriate computer programming language. 

The floor controller process 464 begins at step 466 by opening the 
database tables in the file server. As described above, the file server 
includes a commercially-available database program which stores the 
machine activity information as well as player tracking information and 
associated system characteristic parameters. This step 466 can also 
include fetching some or all of these system characteristics in order to 
trigger certain events such as bonus jackpots, as described below. 

In step 468, the floor controller terminates any active player 
tracking sessions in the database. Because player tracking may have 
been in progress when the floor controller became inoperable, when the 
floor controller powers up or becomes operable, there may be player 
tracking sessions initially active. In this step, the floor controller 
terminates any such active player tracking sessions in order to place the 
database in an initial state. 
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Another step that the floor controller executes after beconnng 
operable is to place an initial machine search message in an ou pu 
n,essa.e .ueue 470. This search message is used the floor controm^r 
to dete,n.ine which machines are connected to the floor controller Th,s 
output message is suhse,uently transmitted to all of the maclunes 
coupled to thefloorcoutrollernsingaglobalmessageformat,asdescr*ed 

below with reference to FIG. 31. In the preferred embodiment of the 
invention, the message handling is through the use of message queues. 
Furthermore, the preferred embodiment is both an output queue for 
outgoing messages from the floor controller to the machines and an mput 
message queue for messages coming from the machines to the floor 
controller. Queues are well-known data structures in the art of computer 
science and are therefore notfurther discussed herein. Alternatwely. the 
„,essage-handling could be done without the use of the queues. In such 
an embodiment the outgoing messages would be sent immediately rather 
than being queued, and any incoming messages would be processed 

immediately. xaA '.c. 

The bulk of the work performed by the file server process 464 .s 

performed in message processing step 472. In this step, the floor 
controller processes all messages sent to or received from the machmes 
connected thereto. This step will be described further below w.th 
references to FIGS. 29 through 31. 

The process 464 also includes a system monitoring step 474. Th,s 
system monitoring step 474 administers certain system-wide events^ 
, These system-wide events include the counting-related events and 
bonusing events. The floor controller continuously checks to see whether 
any of these events have been triggered. If any event has been triggered. 
suchasabonusingevent.thefloorcontrollertakestheappropriateact.on 

to handle the event. The event may be triggered by the time and day or 
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The final step ,n process embodiment, the 

a termination condition m step 476. In the P ^^^^^^ 
n.r controUer cheCs l^^^^^^ ^:- te Jnates the process 
r:rE"c:e;ri:r..efloorcontroner,oopsha*t^ 

I themeTsage-processingstep and the system monitoring step are 
wherein the message pi loor, 472-476 until the 

repeated. The floor controller conUnues m the loop 



termination condition is sensed. 

2. MESSAGE PROCESSING 



s 
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2 MESSAGE rKUOii.^ox.-,w 

^3 described above, the floor controUer acts as a gaU.ay between 

, . ^ fhP file server, as shown m FIG. 1. 
.he machines connected "^^^ ^^^^^^^^^^^ ^....e activity 
Tire floor controfler is respons.bla ^""^ ^ The floor controller 

rrr— :r r ......... ~ 

accomplishes this comiuui , ^ • via 29 

f«r^ 4.72 is shown in more detail in Fl(^. ^y. 

message processmg step 472 is show controller 
The first step in processing the messages is for the 
The first step P .^^put message queue to 

to send any messages that are queued p As described 

the appropriate data communication node m step 480. 
the appi P simple data structure that is usea 

above, the output message ' , ,,.«„,«on 

.3torean,pendi„^^^^^ 

address by which the floor con ^^^.^ee to Next the floor 

data communication nodes -^Z^^^-^ 
controller receives any mcommg m ssa e 

nodes coupled to the floor controller m step 

message has been received, the floor ;;\,,„,,^486. 
„datarncludeai « — the 

^rrdrolCrtl. in s.p t,. floor coutro„er 
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.eads t.e nex. b,te in the inco„-ing n.essage. and .n step 486 the flo^r 
cont^oUer *ec.s to see whether this is the last byte .n the n^essa.e^ In 
The preferred e^bodin^ent, the n^essage includes a n,essage ien.th fle d 
w^i btdicates the nun^ber of data bytes included in the n>essa.e. In 
li tase a floor controller in step 4B6 checks to see whether the nun>W 
Xtes :ead in step 484 is e,ual the „un.ber of bytes specified by the 

~n!:ri" -essa. data has been parsed out of the incon^in. 
n,essage the floor controller takes the appropriate match in response to 
The les a,e data in step 488. This step is described further below w.h 
reference to FIGS. 30 and 31. Following the message-handhng step 488 
hefloorcontro.lerchecKsinstep490todetern,inewhetheranyrespor.e 

din. The floor controller makes this determination by checkmg a 
irri—ress st^cture which indicates ^ 
controller needs to respond to any previous message. I - 
pending, the floor controller .ueues up an appropr.ate outgorng mess ge 
penamg, ,„„ia9 Otherwise, the floor controller 

in the output message queue m step 492. Otherwis , 

completes the message processing step 472. 

Referring now to FIG. 30, the message-handhng step 488 . shown 
l„ more detail. The message-handling step begins by ver.fymg that he 
message data corresponds to a valid massage m step 496. In the 
rrefLedembodimen,themessageinc,udesacyc,ical redundancy check 

Sc by which the floor controller can determine whether the message 
!val d or corrupt. Only if the message is valid will the 
. performanyadditionalmessage-handlingsteps. TheAoorcontroUe a. 
parses through the message in step 496 to determme what type he 
mess ge is. The message type determines the appropriaie floor controller 
TctL: in the preferred embodiment, tire messages include a command 
code which indicates the type of message. 
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The first type of message can be one which includes new met^r 
information. The floor controUercheci.sinstep 498 todeterxnine whether 

the message includes this type of information. If the message .ncludes 
new meter information, the floor controller saves the new meter 
informationlocally in step500. Thefloor controllermaintains local cop^s 
of the meter information in order to minimize the amount of traffic on the 
high-speed network. Because the machine meters change so rap.dly. 
forwarding this new meter information on to the file server t ~ 
of these meters is altered would produce an e.cess.ve amountof ne work 
traffic on the high-speed network. Therefore, in the preferred 
embodiment, thefloorcontrollersaves this newmeterinformationlocally 

in step 500 and only forwards the new information on to the file server 
after a predetermined amount of time has elapsed. 

Another type of message is one which requests data. The floor 
controller checks in step 502 to determine whether the message type ,3 
one requesting data. Typically, these data requests will be for player 
tracking information such as where a player inserts a card into a card 
reader whereupon the data communication associated therewith sends 
the identification number encoded on the card to the floor controller 
requesting the player tracking data associated with the player 
identification number. If the floor controller detects a data request m 
step 502, the floor controller looks up the requested data in the database 
on the file server in step 504. Also, in step 604. the floor controller marks 
a response pending in the transactions in progress structure to mdrcate 
that this requested data needs to he sent back to the DON. As descobed 
above, the floor controller queues up outgoing messages respons.ve to the 

transactions in progress structure. 

Anothermessagetypeisoneusedbythefloorcontrollertoestabhsh 

new machine addresses. The floor controller periodically checks to 
,„ determine whether any new DON has been coupled to its assoc.ated 



current loop networks in order to assi^ a unique address ^ that 
n^achine In step 506. the floor controller checks to see whether the 
rc:::: n.essa.e is in response to such a process. H the inco^n. 
n^essage is in response to a n^achine search, the floor con roller a.s.,ns 
a new machine address to the responding machine m step 508 The 
entire process of assigning new machine addresses is descrrbed below 

with reference to FIG. 31. 

Finally the floor controller in step 510 handles any mxscellaneous 
messages. These miscellaneous messages are used primaoly for 
debugging and trouble-shooting the machines. 

3 ASSIGNING Gaming Device addresses 
As described above, in the preferred embodiment of the invention, 
the floor controller uses a shorthand token representation of the DON s 
unique identification number to address the DON. In the preferred 
embodiment, a single byte address is used to address a DON on any g.ven 
current loop. This one-byte address allows up to 256 DCNs to be 
supported on any given current loop network: In the preferred 
embodiment, only 64 such DCNs are connected U. a single current loop 
network and therefore the single byte address is more than adequate^ 
The single byte address substantially reduces the amount of traffxc on he 
current loop network by reducing the number of bytes from four m the 
unique identification number to one for the shorthand token 

representation. , 

The floor controller is responsible for generating the unique smgle 
, byte address for each data communication node on a given -rent loop 
network. The process 508 of assigning unique addresses to the DCNs on 

the current loop network is shown in FIG. 31. The process begms by 
defining a range of unique identification numbers in step 512. In.Ually 
this will be a large range. 



Next the floor controller sends out a message to all of the DCNs on 
the current loop network in step 514. The floor controller communicates 
with the DCNs by using a standard communication protocol. In the 
preferred embodiment, this protocol defines a message format includmg 
a destination ID. a source ID, a message length, a data packet and a CRC. 
Other message formats could be used as well. Using this format, the floor 
controller can communicate with all of the DCNs on the current loop 
network by using a global destination address in the message. Th.s 
global destination address would indicate to the DCNs that this message 
is intended for all DCNs on the current loop network. This global 
message would include two unique identiflcation numbers that, taken 
together, define the range of unique identification numbers estabhshed 
in step 512. 

The individual DCNs then checks to see whether their unique 
identification number falls within this range. If a DCN's unique 
identification number falls within this range and the DCN does not have 
an address assigned thereto, the DCN then responds to this global 
message by sending a reply message in response that includes the unique 
identification number of that DCN. In the event that more than one DCN 
has a unique identification number that falls within this range a network 
collision will occur and the message will be corrupted. The process 508 
checks for this condition in step 516. This condition is indicated by an 

invalid CRC in the message. 

In the event of a network coUision, the floor controller can limit the 
range of unique identification numbers by repeating step 512 in the hope 
of eliminating this network contention. 

If the response has a valid CRC, the floor controller assigns a 
unique address to the responding DCN, as identified by the unique 
identification number in the response, in step 518. The floor controfler 
, then transmits this address along with the corresponding unique 
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identification nun>ber in an assi^mentn>essa.e to all of the DON. us.ng 
a global destination address in step 520. The DCNs then process th.s 
message and in the event that the unique identification number included 
in the message corresponds to the DCN's unique identification number, 
the DON adopts the address included in the message. Once the DON has 
been assigned an address in this manner, the DON will interpret all 
subsequent messages having a destination address equal to the assigned 
DCN address as being directed to that DON. The above-descr*ed 
address assignmentsequenceisrepeatedforeachoftheremainingDCNs 

on the current loop network in step 522. The fioor controller contmues 
this process until the entire range of unique identification numbers has 
been covered and no more network collisions occur. 
4. System Monitorino 
Referring now to FIG. 32, the system monitoring step 474 will now 
be described. The floor controller is now responsible for monitormg 
certain system-wide conditions to determine whether certain events need 
to occur The system monitoring step also handles request for particular 
machine information. Thus, in step 524, the floor controller determines 
whether a new request has been placed in the data base for such 
particular machine information. If such a request has been placed, the 
floor controller responds to the special request for data in step 526 by 
sending a message to the particular machine requesting the reqmred 
information. Once the required information has been received, the floor 
controller processes this information accordingly. 

The floor controller also monitors the locally-stored meter 
information in step 528. If the locally-stored information is changed, the 
floor controller saves the latest information to the data base in step 630. 
As described above, the floor controller saves the meter informaUon 
locally in order to minimize the traffic to the file server over the h,gh 
0 speed network. 
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The floor controller also monitors the system for certain event 
triggers in step 532. These triggers can be stored in the data base and 
fetched by the floor controller during its power-up procedures. These 
triggers indicate if and when certain events occur. Examples of event 

triggers include: the drop period, the end-of-day, the bonus period, etc. 

If an event trigger has occurred, the floor controller handles the event m 

step 534. 

The handle event step 534 is shown in more detail in FIG. 33. The 
events can basically be bifurcated into accounting events and bonusing 
events Accounting events refer to the data communication activity of the 
system. The accounting events are typically triggered by a certam time 
of day such as the end of day or the drop period. If an accounting event 
has been triggered, the floor controller performs the required data base 
operations in step 538. This step involves updating all of the locally- 
stored meter information and storing the updated meter information into 
the data base. 

The other type of event can be referred to as a bonusing event. The 
floor controller checks to see whether the event is a bonusing event in 
step 540 The bonusing events can also be triggered by the time of day. 
For example, the bonusing event may be triggered from midnight to 4:00 
a m on weekdays. These bonusing periods can be specified in the data 
base If the triggered event is a bonusing event, the floor controfler 
inserts a corresponding reconfiguration message in the output message 
queue in step 542. The reconfiguration message includes a 
reconfiguration command that is sent to an appropriate machine. The 
machine, upon receiving the reconfiguration command, reconfigures its 
payout schedule in accordance with the received reconfiguration 
command. According to the invention, there are many different 
reconfiguration commands to implement a multiplicity of different 
0 bonusing events. One reconfiguration command specifies that the 
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xnachine should reconfigure its payout schedule to be a multiple of its 
default payout schedule. This reconfiguration command can also specify 
that the multiple payout schedule should be limited to a predetermined 
percentage of the coins in. This reconfiguration command can further 
specify that the multiple payout schedule should be limited to only when 
the maximum coins are played. This reconfiguration command can 
further specify that the multiple payout schedule should be limited to 
payouts in a specified range. This reconfiguration command can also 
specify the multiple payout schedule should payout only when a 
predetermined level of player activity is reached. 

Another reconfiguration command allows any number of machmes 
on the network to be combined in a common jackpot having a common 
jackpot payout schedule, wherein the reconfiguration command 
reconfigures the selected machines to payout in accordance wxth the 
common jackpot payout schedule. In this case, the reconfiguration 
xnessage would be queued up for each of the selected machines to be 
combined in a common jackpot. One example of a common jackpot xs a 
progressive jackpot. Unlike the prior art progressive jackpot systems, 
however, the progressive jackpot according to the invention is not hmxted 
to a predetermined number of machines. In the prior art progressive 
jackpot systems, a bank of machines are connected to a common 
progressive jackpot controller and only those machines can be mcluded 
in the progressive jackpot. In contrast, any machine on the network, 
including those connected to other floor controllers can be combined mto 
a common progressive jackpot. Moreover, the number of progressive 
jackpots is not limited by the number of floor controllers since one floor 
controller can manage more than one progressive jackpot. 

Another reconfiguration command permits the system to implement 
so-called "automatic mystery jackpots." These "mystery" jackpots allow 
a machine to payout a mystery jackpot even when a jackpot was not won. 
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Instead, the reconfiguration command can specify that the mystery 
jackpot is to occur after a certain number of coins, a certain number of 
handle pulls, or a variety of other conditions specified by the 
reconfiguration commands. These mystery bonuses provide the casino 
with another way to induce additional gaming activity. 

5. BONUS Control 
Referring now to FIG. 34, a method 550 for controlling the 
conditions under which the above-described bonus activities are activated 
is shown. It is essential for the system to have complete control over the 
amount and conditions under which a bonus is paid out in order to insure 
the profitability of the bonusing system. The method 550 described below 
provides the required control. 

The method 550 begins in step 552 by disabling or turning off the 
bonuses in the individual machines. This is accompUshed by sending a 
message to the individual DCNs to turn off or deactivate bonusing. Next, 
the floor controller monitors the activities of the individual machines 
connected thereto. This step includes monitoring the coins in and 
bonuses paid for the individual machines, as described above. In step 
556, the floor controller modifies a bonus pool by a predetermined 
percentage of all coins played. The bonus pool is essentially a pool of 
monetary resources that can be allocated for bonus awards. In the 
preferred embodiment, a predetermined percentage of the monetary value 
of the coins played are added to the bonus pool. Also in this step, any 
bonuses paid by the gaming devices are also measured and subtracted 
from the bonus pool. The use of the bonus pool will become more 
apparent when the other steps are described hereinbelow. 

In step 558, the floor controller determines whether or not bonusing 
is active. If bonusing is active, the floor controller next determines 
whether the bonus pool amount has dropped below a predetermined 
minimum level called the "turn-off' level in 560. This minimum amount 
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or floor can be set by the casino and provides a buffer to account for large 
bonus awards and/or multiple bonus awards that could cause the bonus 
payout to exceed the bonus pool. Therefore, if the bonus pool drops below 
the turn-off level, the method 550 branches back to step 552 and turns 
off bonusing. As will described further below, the bonusing remains off 
until such time as the bonus pool builds up past another minimum level 
called the "turn-on" level. 

Returning to step 558, if the bonus is currently not active, the floor 
controller determines at step 562 whether the bonus pool has reached a 
predetermined turn-on level. This turn-on level can also be set by the 
casino and provides a buffer above the turn-off level to insure that the 
bonusing does not behave erratically, i.e., bonusing rapidly switching 
between on and off. If the bonus pool is not above the turn-on level, 
bonusing is again turned off in step 552. 

If the bonus pool has reached the turn-on level, the floor controller 
checks to see whether other bonus conditions are met at step 564. These 
bonus conditions can include, but are not limited to, a minimum period 
of time since the last bonus activation, a minimum level of play in the 
time period prior to the bonus pool reaching the turn on level, a 
predetermined time of day, or other predetermined conditions. These 
conditions give the casino additional control over the bonusing 
promotions. If the conditions are not met. the method 550 branches back 
to step 552 where the bonusing is again turned off. If, however, the 
conditions are met in step 564, the bonus is turned on at step 566 and the 
method 550 branches to step 554 where the machine activity is again 
monitored. 

In the preferred embodiment, the method 550 is embodied in 
software that is executed by each of the floor controllers in the system. 
These floor controllers are then responsible for activating or deactivating 
the bonusing for the individual machines connected thereto. The system 



allows the floor controller to have multiple bonus pools and to have 
certain of the machines associated with a given bonus pool. Thus, the 
floor controller can implement multiple bonusing promotions 
simultaneously. 

This system also allows for machines connected to different floor 
controllers to be combined into a single bonusing promotion. In this case, 
one of the floor controllers assumes primary responsibility for managing 
the bonus pool while the other floor controllers act as intermediaries 
between the primary floor controller and the machines connected to the 
other floor controllers. Thus, the system according to the invention allows 
for much greater flexibility in running bonusing promotionals than 
heretofore possible. Prior art systems required certain predetermined 
machines to be connected into a bank for any given bonus award such as 
a progressive bonus. The system according to the invention allows any 
machine in the casino to be combined in a bonus type situation. The 
system also insures that the bonusing promotionals will operate 
substantially in the black, i.e., the bonus pool is greater than the bonus 
payouts. 

Having described and illustrated the principles of the invention in 
a preferred embodiment thereof, it should be apparent that the invention 
can be modified in arrangement and detail without departing from such 
principles. For example, although an Ethernet network was described in 
the preferred embodiment of the invention, other high-speed networks 
such as wireless networks could be used in place thereof. I claim all 
modifications and variation coming within the spirit and scope of the 
following claims. 
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The invention previously described herein may provide advantages as described 
below. 

One advantage is that any of the casino's machines can be incorporated into a 
bonus promotion. 

5 Another advantage is that several bonus promotions can operate 
simultaneously. 

A further advantage is the ability to record each and every machine transaction 
including time of play, machine number, duration of play, coins in, coins out, 
hand paid jackpots and games played. 

1 0 A further advantage is the ability to associate a player with a certain machine. 

A further advantage is the ability to perform more targeted direct mailing based 
on individual play. 

A further advantage is the ability to calculate a theoretical win exactly. 

A further advantage is the ability to generate jackpot announcements, which 
1 5 provides for, among other things, better slot tournaments. 

A yet further advantage is the ability to quickly and easily add new machines to 
the network. 

IVIodifications and variations such as would be apparent to a skilled addressee 
are deemed to be within the scope of the present invention. 

20 Throughout this specification, unless the context requires otherwise, the word 
"comprise", or variations such as "comprises" or "comprising", will be understood 
to imply the inclusion of a stated integer or group of integers but not the 
exclusion of any other integer or group of integers. 
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THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS 

1. A method of operating gaming devices interconnected by a computer 
network to a host computer having a user-operated input device comprising: 

associating each gaming device with a unique address code; 

5 preselecting less than all of the gaming devices interconnected by the 

computer network responsive to a user-effected action at the input device 
that identifies the preselected gaming devices with the respective 
associated address codes; 

using the network to track the amount of money played on the 
1 0 preselected gaming devices; 

allocating a predetermined percentage of the money played to a bonus 
pool; and 

issuing a command over the network to cause a bonus to be paid from 
the bonus pool by one of said preselected gaming devices upon the 
1 5 occurrence of a predetermined event. 

2. A method according to claim 1, wherein said preselected gaming devices 
comprise a first group of gaming devices made up of less than all the gaming 
devices interconnected by the computer network and wherein said method 
further comprises: 

20 preselecting a second group of gaming devices responsive to a user- 

effected action at the input device; 

using the network to track the amount of money played on the second 
group of gaming devices; 
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allocating a predetermined percentage of the nnoney played on the 
second group of gaming devices to a second bonus pool; and 

issuing a command over the network to cause a second bonus to be paid 
from the second bonus pool via one of said gaming devices in the second 
5 group upon the occurrence of a second predetermined event. 

3. A method according to claim 1 or 2, wherein the predetermined event 
comprises a transaction at the gaming device to which the bonus is paid. 

Dated this TWENTYSIXTH day of NOVEMBER 1999 

0 

ACRES GAMING, INC. 
Applicant 
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Wray & Associates 

Perth, Western Australia 

Patent Attorneys for the Applicant 
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